GitHub представил гайд по первым workflow в Actions

GitHub опубликовал новый материал из серии GitHub for Beginners, посвящённый GitHub Actions и созданию первого автоматизированного workflow. Это часть третьего сезона обучающих материалов для начинающих пользователей платформы.

GitHub Actions — это платформа для CI/CD и автоматизации, встроенная в GitHub. Она позволяет запускать сценарии в ответ на события в репозитории: push, pull request, создание issue, срабатывание расписания и другие. Workflows описываются в YAML-файлах, которые хранятся в каталоге .github/workflows.

В материале объясняются базовые термины: workflow запускается определённым событием, после чего GitHub создаёт один или несколько jobs, которые выполняются на runner — виртуальной машине. Jobs состоят из шагов, которые выполняются последовательно до завершения сценария.

На примере демонстрируется создание простого workflow, который автоматически добавляет метку к новым issues. Для этого предлагается форкнуть пример репозитория, открыть вкладку Actions и выбрать один из предложенных шаблонов, а затем перейти к созданию собственного файла.

Каждый workflow описывается в отдельном .yml-файле с понятным именем, например build-and-test.yml или security-scanner.yml. В примере создаётся файл label-new-issue.yml в каталоге .github/workflows, который будет отвечать за добавление метки к новым обращениям.

Затем задаётся триггер: в YAML-файл добавляется конфигурация, которая запускает workflow при открытии нового issue. GitHub предоставляет широкий набор событий-триггеров, список которых доступен в документации по запуску workflows.

Далее автор переходит к блоку jobs, где определяется, что именно выполнит workflow. Для примера создаётся job с именем label-issues, который запускается на runner с образом ubuntu-latest из пула GitHub. Это указывает, на какой системе будут выполняться шаги сценария.

В job настраиваются permissions, чтобы действия внутри сценария могли читать содержимое репозитория и добавлять метки. Разрешения задаются единым блоком, и их получают все шаги и используемые actions внутри этого job.

Далее добавляются шаги. В них используются два ключевых слова: uses и run. uses подключает готовые actions из GitHub Marketplace, например для checkout кода или настройки NodeJS, а run запускает команды или скрипты — как однострочные, так и многострочные.

В разделе env задаются переменные окружения. Поскольку в примере применяется GitHub CLI, workflow должен получить токен доступа к репозиторию. Для этого используется переменная GH_TOKEN, в которую передаётся временный токен GITHUB_TOKEN, автоматически создаваемый GitHub для каждого job.

Отдельные переменные используются для указания, к какому issue применять изменения, и какую метку добавлять. При этом метка должна уже существовать в репозитории, иначе действие не сможет её назначить.

После создания файла workflow предлагается протестировать его. Изменения нужно запушить и слить в основную ветку, после чего новый сценарий появится в списке workflows в репозитории. Если есть вопросы по push, автор ссылается на предыдущий выпуск серии о добавлении кода в репозиторий.

Для проверки работы нужно перейти на вкладку Issues, создать новый issue через кнопку New issue, указав, что это тест workflow, и отправить его. При корректной настройке триаж-метка добавится автоматически через несколько секунд после создания обращения.

Далее объясняется, как просматривать результаты работы сценария. Во вкладке Actions можно выбрать Label New Issues, чтобы отфильтровать запуски, а затем открыть нужный workflow и перейти в job label-issues, где отображаются все шаги и их статусы.

Эта детализация помогает при отладке, если workflow ведёт себя не так, как ожидается. На той же странице доступна кнопка Re-run all jobs, которая позволяет повторно запустить сценарий для конкретного случая выполнения.

Если требуется временно остановить работу сценария, это делается через вкладку Actions. Нужно выбрать Label New Issues, нажать на три точки рядом с поиском и выбрать Disable workflow. В таком случае workflow перестаёт запускаться, но файл остаётся в репозитории и его можно снова включить.

Вкладка Actions служит единым центром управления workflow: здесь можно отслеживать деплой, состояние runners, метрики, производительность и кэш. Также из этого интерфейса можно просматривать и редактировать YAML-файлы сценариев.

Отмечается, что GitHub Actions применимы гораздо шире, чем простая разметка issues. Платформа подходит для публикации пакетов, приветствия новых контрибьюторов, сборки и тестирования кода, а также выполнения проверок безопасности.

Для дальнейшего изучения GitHub рекомендует документацию по GitHub Actions и предлагает экспериментировать с созданием собственных сценариев. Дополнительно можно пройти практические упражнения GitHub Skills, чтобы быстрее освоить автоматизированные workflows на Actions.

Автор материала — Кедаша, Developer Advocate в GitHub. Она делится опытом работы разработчиком и рассказывает, что ей важно помогать сообществу осваивать технологии и карьеру в IT, в том числе через такие обучающие серии.

В завершении GitHub обращает внимание на использование ИИ в рабочих процессах: автоматизация triage для отзывов по доступности с помощью AI, агентные workflows с изоляцией, ограниченными выходными данными и подробным логированием, а также реальный опыт разработчиков, которые внедряют инструменты ИИ в production-процессы.

Источник: материалы и обучающие руководства GitHub.

Читать новости ИИ и технологий в Telegram.


Оцените статью
Gimal-Ai