Использование триггеров для управления при запуске рабочего процесса
Теперь у вас есть рабочий рабочий процесс, который развертывает файл Bicep в среде Azure. Однако всякий раз, когда вы изменяете файл, необходимо вручную запустить рабочий процесс. В этом уроке вы узнаете, как активировать рабочий процесс для автоматического запуска при изменении кода Bicep.
Заметка
Команды в этом блоке показаны для иллюстрации концепций. Еще не выполняйте команды. Вы будете практикуть то, что вы узнаете здесь в ближайшее время.
Что такое триггер рабочего процесса?
Триггер рабочего процесса — это условие, которое при выполнении автоматически запускает рабочий процесс на основе создаваемых правил. Триггеры можно задать для запуска рабочего процесса с запланированными интервалами. Вы также можете задать триггеры для запуска рабочего процесса каждый раз, когда файл в репозитории изменяется. Вы можете выбрать второй вариант, так как рекомендуется выполнять все тесты и шаги развертывания при каждом изменении кода.
Если вы не используете автоматический триггер, кто-то может внести изменения в Bicep-файл и даже зафиксировать его и отправить его в репозиторий, но если они забыли запустить рабочий процесс, то в файле Bicep будет разница между определениями ресурсов в файле Bicep и ресурсами, развернутыми в среде Azure. Предположим, что совершается ещё пара фиксаций и push-операций, но они не развернуты. Если кто-то вносит ошибку или неправильно настроенную конфигурацию в файл Bicep при одном из таких изменений, может быть трудно отследить ошибку среди нескольких коммитов, которые затем развертываются одновременно. Через некоторое время вы перестанете доверять вашему коду Bicep как точному представлению вашей инфраструктуры, и её ценность снижается.
Когда вы настраиваете рабочий процесс так, чтобы он запускался каждый раз при обновлении ваших файлов, в тот момент, когда ваши изменения отправляются, рабочий процесс начинает выполняться. Вы получаете мгновенный отзыв о действительности изменения, и вы можете быть уверены, что ваша рабочая среда всегда обновлена.
Триггеры push-событий
Распространенны й тип триггера — это триггер push-события , который также называется триггером непрерывной интеграции или триггером CI. При использовании push-триггера каждый раз, когда вы вносите изменения в определенную ветвь, запускается рабочий процесс. Если вы фиксируете и отправляете изменение в другую ветвь, рабочий процесс не активируется и не выполняется. Этот тип триггера обычно используется против вашей ветки по умолчанию или основной ветки, с этим кодом:
on:
push:
branches:
- main
Триггер срабатывает при изменении нескольких ветвей
Триггеры можно настроить для запуска рабочего процесса в определенной ветви или в наборах ветвей. Например, предположим, что вы создаете ветви выпуска , содержащие код, который будет развернут для определенного выпуска проекта. Можно использовать такие имена ветвей, как выпуск/v1, выпуск/v2и т. д. Вы хотите запускать рабочий процесс, как только код изменяется в ветке, которая начинается с имени release/ или. Можно использовать подстановочный знак **:
on:
push:
branches:
- main
- 'release/**'
Вы также можете исключить определенные ветви. Предположим, вы сотрудничаете с участниками команды в проекте. Ваши коллеги создают ветви функций , чтобы попробовать свои идеи в файлах Bicep. Все ветки фич имеют такие имена, как feature/добавить базу данных, feature/повышение производительностии так далее. Вы хотите автоматически запускать рабочий процесс во всех ветвях, кроме ветвей компонентов, создаваемых коллегами. Используя свойство exclude, убедитесь, что рабочий процесс не активируется автоматически для изменений в функциональных ветках.
on:
push:
branches-ignore:
- 'feature/**'
Заметка
Некоторые ветви можно исключить с помощью символа !. Предположим, вы хотите запустить рабочий процесс для главной ветки и всех релизных веток, за исключением альфа-релизов. Для выражения этого можно использовать символ !:
on:
push:
branches:
- main
- 'release/**'
- '!release/**-alpha'
Вы не можете использовать branches и branches-ignore вместе в одном триггере, поэтому символ ! обеспечивает гибкость для управления поведением триггера.
Фильтры путей
Иногда в репозитории есть файлы, которые не связаны с развертыванием. Например, в вашем репозитории может быть папка deploy, содержащая код Bicep, и подпапка docs, содержащая файлы документации. Вы хотите активировать рабочий процесс, когда любой пользователь вносит изменения в любой из файлов Bicep в папке развертывания, но вы не хотите активировать рабочий процесс, если кто-то только изменяет файл документации. Чтобы настроить триггер для реагирования на изменения в определенной папке в репозитории, можно использовать фильтр пути :
on:
push:
paths:
- 'deploy/**'
- '!deploy/docs/**'
Если кто-то зафиксирует изменение, которое обновляет только файл документации, рабочий процесс не запускается. Но если кто-то изменяет файл Bicep или даже если он изменяет Bicep-файл в дополнение к файлу документации, триггер запускает рабочий процесс.
Заметка
Вы также можете использовать paths-ignore, которая работает аналогично ключевому слову branches-ignore. Однако вы не можете использовать paths и paths-ignore в том же триггере.
Планирование автоматического запуска рабочего процесса
Рабочий процесс можно запустить по заданному расписанию, а не в ответ на изменение файла. Например, вы можете запускать ночной выпуск кода Bicep или автоматически развертывать тестовую среду каждый утром. Используйте ключевое слово schedule и задайте частоту с помощью выражения cron:
on:
schedule:
- cron: '0 0 * * *'
Заметка
Выражение cron — это специально отформатированная последовательность символов, указывающая, как часто должно происходить что-то. В этом примере 0 0 * * * означает, что выполняется каждый день в полночь по времени UTC.
В YAML-файле необходимо добавить кавычки вокруг строк, содержащих символ *, например выражения cron.
Событие по расписанию всегда запускает рабочий процесс на основной ветке вашего репозитория.
Использование нескольких триггеров
Вы можете объединить триггеры и расписания, например в этом примере:
on:
push:
branches:
- main
schedule:
- cron: '0 0 * * *'
При создании триггера ветви и запланированного триггера в одном рабочем процессе, рабочий процесс выполняется каждый раз, когда файл изменяется в триггере и по заданному расписанию. В этом примере рабочий процесс выполняется каждый день в полночь по UTC, а также при изменениях, отправленных в основную ветвь.
Совет
Рекомендуется задать триггеры для каждого рабочего процесса. Если вы не зададите триггеры, то по умолчанию ваш рабочий процесс будет автоматически запускаться каждый раз, когда изменяется файл в любой ветке, что часто бывает нежелательно.
Триггеры веб-перехватчика
GitHub также предоставляет события веб-перехватчика, которые выполняются автоматически при наступлении определенных событий в вашем репозитории. К этим событиям относится создание ветки, обновления обращений в GitHub или изменения пулл-реквестов. Как правило, эти события не требуют выполнения рабочего процесса развертывания Bicep, но вместо этого можно запустить другую автоматизацию.
Управление параллелизмом
По умолчанию GitHub Actions позволяет одновременно запускать несколько экземпляров рабочего процесса. Это может произойти при выполнении нескольких фиксаций изменений в ветке в течение короткого времени или если предыдущий запуск не завершился к моменту следующего срабатывания вашего расписания.
В некоторых ситуациях наличие нескольких параллельных запусков рабочего процесса не является проблемой. Работая с рабочими процессами развертывания, сложно обеспечить, чтобы выполнение рабочего процесса не перезаписывало ресурсы или конфигурацию Azure неожиданными способами.
Чтобы избежать этих проблем, можно применить управление параллелизмом. Используйте ключевое слово concurrency, а затем укажите строку, которая единообразна во всех запусках вашего рабочего процесса. Обычно это жестко закодированная строка, как в следующем примере:
concurrency: MyWorkflow
Затем GitHub Actions гарантирует, что он ожидает завершения любого активного рабочего процесса перед началом нового запуска.