Некоторые стандартные проблемы, с которыми сталкиваются новые пользователи GitHub Actions, заключаются в том, что их рабочие процессы не запускаются или отсутствует пользовательский интерфейс для этого. В начале все начинают с триггера on: push, но наступает время, когда вы хотите выполнять некоторые рабочие процессы только на ветке по умолчанию (основной). Поэтому вы ограничиваете триггер on: push только этой веткой:
on:
push:
branches:
- main
Когда вы следуете лучшим практикам, вы хотите внедрить процесс, основанный на Pull Request, чтобы предотвратить внесение изменений в репозиторий одним человеком. Это означает, что вы вносите изменения в рабочие процессы в ветке фич, а не в основной ветке.
Что происходит дальше? Смотрите шаги ниже. Вы можете начать с самого начала (запланированный запуск не начат) и затем двигаться вниз к более конкретным примерам. Это также представляет собой порядок, в котором часто возникают подобные вопросы.
Фото Sora Sagano on Unsplash
Запуски по расписанию не начинаются
Когда вы добавляете свое первое расписание для ежедневной пробежки, вы можете быть удивлены тем, что она не начинается по установленному вами расписанию. Вы можете почесать голову и подождать несколько дней, но ничего не произойдет.
on:
schedule:
- cron: '30 5,17 * * *'
Причина этого в том, что запланированные запуски запускаются только из ветки по умолчанию (main). Несколько триггеров ведут себя подобным образом, например, триггер Pull Request (+Status), триггеры issue / label / comment и т.д.
Таким образом, если в вашем рабочем процессе есть расписание, а вы не находитесь в ветке по умолчанию, рабочий процесс не запустится. Это мера безопасности, чтобы никто не смог создать рабочий процесс, который запускается по расписанию, а затем создать запрос на вытягивание в хранилище, в котором есть рабочий процесс по расписанию. Тогда запланированный рабочий процесс запустится на запросе на вытягивание, и злоумышленник сможет сделать что-то вредоносное. Это хорошая вещь, но она может быть запутанной, если вы только начинаете. Решение заключается в том, чтобы убедиться, что вы находитесь на ветке по умолчанию при создании запланированного рабочего процесса, а значит, вам нужно объединить свои изменения, чтобы он запустился по вашему расписанию.
UI ручного запуска (workflow_dispatch) не отображается
Это обычный следующий шаг, когда расписание не запускается: вы просто добавляете триггер диспетчеризации рабочего процесса к рабочему процессу, чтобы запустить его вручную. Но поскольку это новый рабочий процесс, который еще не существовал, пользовательский интерфейс для его запуска не виден! Это то же самое, что создать новый файл рабочего процесса с этим триггером одним махом.
Для ручного запуска пользовательский интерфейс доступен только в ветке по умолчанию. Вы можете выбрать, из какой ветви запускать выполнение, и иметь входы, доступные из ветви по умолчанию. Но чтобы пользовательский интерфейс был виден, файл и триггер должны находиться в ветке по умолчанию.
У вас есть два варианта продолжения и запуска рабочего процесса:
- Перейти к следующему шагу и использовать ‘on: push’.
- Запустить новый рабочий процесс из ветки с помощью API.
Запуск рабочего процесса с помощью API
Вы можете запустить отправку рабочего процесса (как и отправку хранилища, если на то пошло) с помощью пользовательского интерфейса и даже запустить его из филиала.
Вам нужно сделать (аутентифицированный) вызов url для вашего рабочего процесса:
‘https://api.github.com/repos/{OWNER}/{REPO}/actions/workflows/{WORKFLOW_ID}/dispatches’.
На самом деле рабочие процессы имеют ID под обложкой, но вы также можете использовать имя файла, которое легче читать. Так, если рабочий процесс называется get-action-data.yml и он находится в репозитории rajbos/actions-marketplace, то это будет выглядеть так: https://api.github.com/repos/rajbos/actions-marketplace/actions/workflows/get-action-data.yml/dispatches.
Примечание: не включайте слеш в конце url, API GitHub не принимает это и возвращает ошибки.
Мой инструмент для этого — Postman, потому что я могу хранить в нем свои запросы, и он живет в своем собственном окне. Это позволяет легко переходить к нему и нажимать CTRL+ENTER для запуска вызова, что очень удобно при создании рабочих процессов.
Дальше: нажимать?
Последний вариант, который у вас есть, — это просто запускать рабочий процесс всякий раз, когда кто-то вставляет данные в хранилище. Вы можете решить, должно ли это происходить на определенных ветках, но лучший совет здесь — включить фильтр путей (см. документацию здесь).
on:
push:
branches:
- main
- my-test-branch
paths:
- 'src/**'
- '.github/workflows/my-workflow-file.yml'
Я часто запускаю рабочий процесс по крайней мере на тестовой ветке, но только после того, как соответствующие файлы для этого рабочего процесса будут отредактированы. Обычно это сам файл рабочего процесса и, возможно, некоторые исходные файлы в репозитории, которые используются: при каждом изменении в этих файлах выполняйте рабочий процесс. Это особенно полезно во время разработки рабочего процесса: если вы внесли в него изменение, это хорошее изменение, которое вы хотите запустить рабочий процесс 😄.
Обратите внимание, что это не поможет, если у вас есть конкретные сценарии использования, которые вы хотите протестировать, например, когда кто-то создает комментарий или запрос. Есть и другие способы решения этой проблемы, но об этом в другой статье.