Дополните свой набор инструментов CI/CD рабочими процессами GitHub
Краткая вводная хронология GitHub
GitHub сильно изменился с момента прихода к власти Microsoft, несмотря на конгломератную природу крупных корпораций или, скорее, вопреки ей. Одна из многих вещей, которые значительно продвинулись в GitHub, — это конвейеры CI/CD. GitHub предоставляет много хороших рабочих процессов и других, разработанных сообществом открытого исходного кода в последние годы, и по мере развития технологии их будет еще больше.
Это открыло двери для многих возможностей, поскольку многие компании уже хранят свои исходные коды на GitHub, одном из первых игроков на рынке [исходный код]!
Хотя это может показаться пугающим, но усиление одной компании по сравнению с другими также может открыть множество возможностей и инноваций, поскольку тяга сообщества будет способствовать созданию все большей и большей ценности, которая в конечном итоге принесет пользу всем.
Что такое действие GitHub?
Хотя для многих инженеров это очень тривиально, определение термина имеет решающее значение для начинающих. GitHub Action — это конвейер CI/CD, который вы получаете, если у вас есть учетная запись в GitHub с одним или несколькими репозиториями, каждый репозиторий имеет свои конвейерные рабочие процессы.
Это позволяет вам определить все шаги, которые вы хотите, чтобы они происходили на наборе определенных триггеров. Ниже приведены несколько примеров таких действий:
- Запуск тестов в вашем репозитории при поступлении запроса на извлечение.
- Запуск языковых линтеров в вашем проекте при каждом нажатии.
- Развертывание в dev/prod при публикации новой версии.
Это всего лишь несколько примеров того, что возможно с GitHub Action, и вы можете придумать бесчисленное множество других, в зависимости от требований проекта.
Зачем вам писать собственное действие GitHub?
Мы живем в 21 веке, и почти все программные проблемы уже решены; вам нужно только достаточно внимательно изучить проблемную область, связать все воедино и, в конечном итоге, настроить всю платформу таким образом, чтобы она соответствовала вашим требованиям.
Все то же самое для GitHub Actions, так как уже существует множество определений рабочих процессов, которые вы можете поместить в определение вашего проекта CI/CD, передать правильное значение и получить то, что вы ожидаете.
Это подводит нас к моменту, когда вам, скорее всего, не нужно будет переписывать что-то с нуля.
Но даже в этом случае могут быть случаи, когда:
- Доступные решения не подходят для вашей проблемы
- Сложность проблемы и доступное решение не совпадают
- Решение не является гибким в плане конфигурации
Все это и многое другое — достаточно веские причины, чтобы захотеть написать свой собственный GitHub Action, и именно об этом эта статья.
Мы рассмотрим различные способы написания пользовательского действия GitHub и предоставим практический пример каждого из них.
Как написать собственные действия GitHub?
При написании этой статьи есть три способа написать GitHub Action. Приведенные ниже подходы можно использовать для создания и публикации действия GitHub, либо с открытым исходным кодом и общедоступным для сообщества, либо в частном порядке для вас.
Типы доступных действий GitHub:
- JavaScript: если вы входите в число 17,5 миллионов разработчиков JS или если вы входите в число 65% из 70 000 респондентов опроса Stackoverflow, вам, скорее всего, понравится этот подход, поскольку вы можете написать свою логику с помощью предпочтительный язык.
- Docker: Если вы не являетесь разработчиком JavaScript, как и я, вы найдете это очень интересным, поскольку все, что может быть контейнеризировано, также может быть отправлено как действие GitHub; в наши дни это означает любое приложение, благодаря усилиям многих великих инженеров.
- Composite: последнее, но не менее важное, мое самое любимое, позволяющее объединить несколько действий GitHub в одно, которое также продается как «повторно используемые рабочие процессы для широкой публики».
Поскольку я не являюсь разработчиком JavaScript, я не просто могу читать и в некоторой степени понимать, что он делает, я не буду уделять этому больше внимания, а вместо этого остановлюсь на том, что мне кажется наиболее сильным: Docker и Composite.
Общее определение действия GitHub
Выбирая любой подход к написанию действия GitHub, вам понадобится один важный файл, который будет служить определением вашего действия GitHub.
Имя файла должно быть точно action.yml , и оно должно находиться в корне вашего проекта. Среди прочего, вот что вы указываете в этом файле определения:
- Какие входы
- Как вызвать действие, т. е. какой файл или двоичный файл выполнить
- На какой результат можно рассчитывать
Как и многие другие замечательные файлы определений, это определение представлено в формате YAML, одном из самых противоречивых. Вот пример action.yml, взятый из документации GitHub.
Этот файл состоит из трех основных компонентов; все остальные являются необязательными.
name: это уникальное имя, присвоенное действию. Это имя служит идентификатором, и оно должно быть уникальным, поскольку ему будет присвоен URL-адресgithub.com/marketplace/actions/MY_GITHUB_ACTION, который нельзя дублировать; это относится только к общедоступным действиям, которые предназначены для публикации на GitHub Marketplace и в противном случае не должны быть уникальными.inputs: набор имен, которые действие получит в качестве своих параметров. Подумайте оkubectl get pod --output=yaml, который в данном случае «выход» является параметром двоичного файлаkubectl.runs: важной частью любого Действия является то, где вы определяете «тип» вашего Действия, один из трех типов, описанных выше. Этот «тип» указан под ключомusingи сообщает «бегуну», как запустить ваше действие. При использованииdockerвам нужно будет указать путь к вашему Dockerfile с атрибутомimage.argsне требует пояснений, поскольку он передаетinputsбазовой реализации.
Это определение, если оно указано правильно, сообщит GitHub Runner, как запустить ваше действие. Он действует как точка входа; без него логика, определенная в репозитории, не будет выполняться, так как раннер не знает, как это сделать.
Теперь, когда мы определили схему GitHub Action, давайте завершим аргумент, приведя несколько практических примеров.
Действие 1: написание вашего первого действия GitHub с использованием Docker
Контейнерные приложения получили большое распространение в последние годы по уважительным причинам. Они позволяют вам написать ваше приложение на выбранном вами языке программирования, поместить его в собственную капсулу и распространять везде, по крайней мере, почти.
Даже с учетом ограничения сборки образа для конкретной платформы вы все равно можете создавать материалы и предоставлять их более широкой аудитории; сравните это с эпохой, когда «голое железо» было единственным вариантом, например, нужно было синхронизировать версию JVM, установленную на всех машинах!
Теперь давайте перейдем к реальному коду, где мы разработаем настоящее действие GitHub.
Требование: отправлять уведомление по электронной почте при каждом выпуске GitHub.
После введения, истории и определений пришло время написать код. В этом коде мы будем отправлять электронное письмо списку людей в каждом выпуске GitHub.
Логика реализации не зависит от языка, а реализация — нет. Здесь мы напишем приложение Python, которое выполняет эту работу, используя SendGrid SDK.
Как видите, в коде нет ничего сложного; он получит необходимые входные данные, подготовит электронное письмо и отправит его соответствующим образом. Несколько строк отладки помогают пользователю понять, на каком этапе мы находимся, и обработка исключений, которая ничего не делает, кроме как выводит ее на стандартную ошибку.
Библиотека Markdown используется, потому что мы получаем заметку о выпуске и передаем ее в действие GitHub в формате уценки.
Контейнеризация приложения
Написание Dockerfile — это ключ, который позволяет нам запускать приложение в изолированной среде в любом месте, в любое время и в любой операционной системе.
Если вас интересуют советы и рекомендации по написанию правильного Dockerfile, перейдите по ссылке ниже.
Определение приложения, как отмечалось выше, может выглядеть так:
Конечно, send-email-with-sendgrid.py должен быть исполняемым с надлежащим шебангом. Чтобы сделать его исполняемым, вы запустите chmod +x FILENAME.
Определите действие GitHub
До сих пор мы только писали нашу логику, но ее нельзя использовать в действии GitHub без хорошо и правильно определенного action.yml, и именно здесь начинается следующий шаг.
Нам понадобится файл в формате YAML, который будет определять имя действия, входные данные и способ его запуска, то есть способ передачи аргументов.
Вот как будет выглядеть такой файл.
args, определенные в action.yml, передаются как cmd в док-контейнер. Аргументы те же, что определены с помощью argparse в приложении Python выше.
Опубликовать на GitHub Marketplace
Мы написали весь код логической реализации, необходимый для запуска приложения как действия GitHub. Тем не менее, в качестве последнего шага, если мы хотим опубликовать наше приложение в Рынке и сделать его доступным для поиска, нам нужно будет создать новую версию, что, вероятно, является самым простым шагом.
В качестве демонстрации ниже представлены скриншоты.
Последний флажок жизненно важен, поскольку он указывает, что вы хотите опубликовать свое действие GitHub в Marketplace, что позволит другим людям использовать его. В конечном итоге вы увидите свое действие GitHub в Marketplace, как на картинке ниже.
После такого выпуска GitHub вы и другие пользователи сможете использовать действие GitHub, используя следующий рабочий процесс в формате YAML, размещенный в каталоге .github/workflows/ репозитория.
Это настолько просто, насколько это возможно. Вы, конечно, можете проявить творческий подход и сделать больше причудливых вещей!
Исходный код
Все файлы доступны по ссылке ниже.
Акт 2: Написание вашего второго действия GitHub с использованием оболочки
Крайне важно понимать, что GitHub Runners содержатся в новой виртуальной машине каждый раз, когда они запускаются, и они будут удалены после завершения [источник]. Это означает, что то, что вы сделали в предыдущем запуске, будет недоступно, если вы не сохранили результат, например, GitHub Artifact или GitHub Cache.
Тем не менее, вы можете объединить несколько этапов файла рабочего процесса и опубликовать его как одно действие GitHub, что позволит вам повторно использовать его как единое целое, отсюда и название Многоразовые рабочие процессы.
Этот тип действия GitHub называется составным. Как следует из названия, он состоит из множества других шагов. Это идеально подходит для сценариев, когда для нескольких репозиториев требуются разные этапы CI/CD. Вы не хотите повторять одни и те же шаги везде, а лучше поддерживать один репозиторий и обновлять его соответствующим образом.
Требование: разверните выпуск Helm в кластере Kubernetes.
Мы хотим развертывать Helm Chart с набором настраиваемых флагов в конкретном кластере Kubernetes каждый раз, когда происходит новое нажатие на ветку по умолчанию. Для этого необходимо выполнить следующие шаги:
- Установите конкретную версию Helm, идеально настраиваемую.
- Получите Kubeconfig и файл значений Helm либо в виде строки в кодировке YAML, либо в виде пути к файлу в базовой операционной системе, например, из AWS S3.
- Измените разрешение файла значений Kubeconfig & Helm по запросу пользователя.
- Разверните фактическую диаграмму с настраиваемым именем выпуска.
- Очистка по запросам пользователей, т. е. удаление Kubeconfig и файла значений Helm из соображений безопасности!
Вот как такое требование будет выглядеть в файле определения действия GitHub:
Обратите внимание на значение под .runs.using, которое равно composite, что означает, что мы определим выполняемые шаги в том же файле action.yml.
Эти шаги — это те же самые шаги, которые вы в противном случае поместили бы в любой из файлов, помещенных под .github/workflows/. Единственное отличие — это атрибут shell, который является обязательным ключом для каждого шага. Он сообщает бегуну, как должны выполняться команды. Список доступных оболочек задокументирован здесь.
Синтаксис файла не требует пояснений, а также удобочитаем. Все, что вы видите под атрибутом run каждого шага, представляет собой набор исполняемых команд bash.
Вы также можете поместить любой файл Python или JavaScript в тот же репозиторий и вызвать этот файл из того же файла action.yml, что сделает действие GitHub более мощным и универсальным.
Как это использовать?
По сути, у вас будет определение рабочего процесса, аналогичное приведенному ниже, для использования вышеуказанного действия GitHub.
Исходный код
Все файлы доступны по ссылке ниже.
Заключение
CI/CD значительно облегчила нам жизнь, предоставив нам гибкость в разработке и избавив от бремени ручного и повторяющегося развертывания. В 21 веке и с появлением множества инструментов и технологий, направленных на автоматизацию повторяющихся задач, CI/CD стали одними из самых успешных, которые в наши дни являются неотъемлемой частью каждой компании, что делает их не роскошью, а необходимостью. поддерживать уровень ремонтопригодности на максимальном уровне.
GitHub Actions, один из самых известных наборов инструментов CI/CD, предоставляет множество функций. Чтобы конкурировать с текущими решениями CI/CD, GitHub Actions прошел долгий путь, чтобы обеспечить расширяемость, чтобы люди могли создавать и публиковать свои решения для конкретных требований. Вы сможете найти множество готовых рабочих процессов, которые готовы к вашей производственной битве.
В этой статье мы привели практические примеры того, как написать реальное пользовательское действие GitHub, если вы не можете найти готовое. Имея эти знания в своем наборе инструментов, вы будете неудержимы в том, что сможете создать ценность для себя, своей компании и сообщества.
Отличного вам остатка дня. Оставайтесь с нами, и берегите себя!
Рекомендации
Если вам понравилась эта статья, ознакомьтесь с другими моими материалами, которые также могут быть вам полезны.
