Общие сведения о действиях GitHub

  • 7 мин

Вы можете автоматизировать этапы процесса развертывания с помощью рабочего процесса. Каждый раз, когда вы вносите изменения в код и фиксируете изменения в репозитории Git, рабочий процесс запускает предопределенный процесс. Рабочий процесс может проверить соответствие кода Bicep стандартам качества, а затем автоматизировать действия для развертывания ресурсов в Azure. Процесс определяется в определении рабочего процесса, который вы создаете.

GitHub Actions — это функция GitHub. GitHub также размещает репозитории Git, которые вы используете для хранения и совместного использования кода со своими коллегами. При хранении кода Bicep на GitHub, GitHub Actions может получить доступ к вашему коду для автоматизации процессов его развертывания. В этом уроке вы узнаете о GitHub Actions.

Что такое рабочий процесс?

Рабочий процесс — это настраиваемый повторяемый процесс, определенный в файле, который используется для тестирования и развертывания кода. Рабочий процесс состоит из всех шагов в правильном порядке, которые необходимо выполнить.

При работе с GitHub Actions вы определяете конфигурацию рабочего процесса в YAML-файле. Так как файл YAML рабочего процесса является файлом кода, файл хранится с кодом Bicep в репозитории Git в папке с именем .github/workflows. ФАЙЛ YAML — это структурированный текстовый файл, аналогичный структурированным текстовым файлам Bicep. Вы можете создать и изменить ФАЙЛ YAML с помощью любого текстового редактора. В этом модуле вы будете использовать Visual Studio Code в качестве редактора. Веб-интерфейс GitHub предоставляет средства, которые можно использовать для просмотра и редактирования YAML-файла рабочего процесса, для совместной работы над определением рабочего процесса и управления различными версиями файла рабочего процесса с помощью фиксаций и ветвей.

Бегунов

До настоящего момента вы развернули файлы Bicep с локального компьютера. После написания шаблона Bicep вы развернете его в Azure с помощью Azure CLI или Azure PowerShell. Эти средства используют ресурсы компьютера для отправки шаблона в Azure. Они используют свое личное удостоверение для проверки подлинности в Azure и проверки наличия разрешений на развертывание ресурсов.

Рабочий процесс также должен иметь доступ к компьютеру или GPU с правильной операционной системой и аппаратной платформой, чтобы он смог выполнить действия развертывания. GitHub Actions использует исполнители, это компьютеры, которые настроены на выполнение шагов развертывания рабочего процесса. Каждый модуль runner уже имеет инструменты Bicep и Azure, которые вы использовали в предыдущих модулях, поэтому это может сделать то же самое, что вы делаете с собственного компьютера. Вместо того чтобы человек выполнял команды, служба GitHub Actions дает указание запускающему средству выполнить шаги, которые вы определили в файле YAML рабочего процесса.

GitHub Actions предоставляет несколько типов модулей выполнения для различных операционных систем, таких как Linux или Windows, и различные наборы инструментов. GitHub управляет этими средствами выполнения, поэтому вам не нужно поддерживать инфраструктуру вычислений для средств выполнения. Иногда средства выполнения называются размещаемыми на GitHub или размещаемыми средствами выполнения, так как они размещаются от вашего имени. При запуске рабочего процесса автоматически создается размещенный модуль выполнения. Когда рабочий процесс завершится, хостируемый агент автоматически удаляется. Вы не можете напрямую получить доступ к встроенным агентам, поэтому важно, чтобы ваш процесс содержал все необходимые этапы развертывания вашего решения.

диаграмме, в которой показан рабочий процесс, который выполняется в средстве выполнения.

Заметка

Вы можете создать пользовательский модуль выполнения, который называется локальной. Вы можете создать локальное средство выполнения, если у вас есть определенное программное обеспечение, которое необходимо запустить в рамках рабочего процесса или если необходимо точно управлять настройкой средства выполнения. В этом модуле не обсуждаются локальные runners, но мы предоставляем ссылку на дополнительные сведения в разделе "Сводка".

Триггеры

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

схема, показывающая триггер, инициирующий рабочий процесс.

Шаги

Шаг представляет одну операцию, выполняемую рабочим процессом. Шаг аналогичен отдельной команде, выполняемой в Bash или PowerShell. Для большинства развертываний выполняется несколько шагов в последовательности. Вы определяете последовательность и все сведения о каждом шаге в файле YAML рабочего процесса.

GitHub Actions предлагает два типа шагов:

  • шаги выполнения. Для выполнения одной команды или последовательности команд в Bash, PowerShell или командной оболочке Windows можно использовать шаг выполнения.
  • действия. Шаг действия — удобный способ доступа к различным возможностям без написания инструкций скрипта. Например, существует встроенное задание для развертывания файлов Bicep в Azure. Любой пользователь может написать действие и поделиться им с другими пользователями. Доступен большой набор коммерческих и открытых задач с открытым кодом.

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

Работы

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

Заметка

Каждое задание можно настроить для выполнения на разных исполнителях. Выполнение заданий на разных исполнителях полезно при создании и развертывании решений, которые должны использовать разные операционные системы в разных частях рабочего процесса задачи.

Например, предположим, что вы создаете приложение iOS и серверную службу приложения. Возможно, у вас есть одно задание, которое выполняется в раннере macOS для сборки приложения iOS, и другое задание, которое выполняется в раннере Ubuntu или Windows для сборки бэкенда. Вы даже можете сообщить рабочему процессу одновременно выполнять два задания, что ускоряет выполнение рабочего процесса.

схема, показывающая рабочий процесс с двумя шагами в одном задании.

Базовый пример рабочего процесса

Теперь, когда вы знаете основные понятия GitHub Actions, давайте рассмотрим простое определение рабочего процесса в YAML:

name: learn-github-actions

on: [workflow_dispatch]

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
      - name: 'Run a one-line command'
        run: echo "hello from GitHub Actions"
      - name: 'Run a multi-line command'
        run: |
          echo "We'll add more steps soon."
          echo "For example, we'll add our Bicep deployment step."

Давайте подробно рассмотрим каждую часть файла:

  • name — это имя рабочего процесса. Имя отображается в веб-интерфейсе GitHub.
  • on указывает рабочему процессу, когда его выполнять. В этом случае on: [workflow_dispatch] сообщает GitHub Actions, что необходимо вручную активировать рабочий процесс.
  • jobs группирует все задачи в вашем рабочем процессе.
  • say-hello — это имя первого и единственного задания в этом рабочем процессе.
  • runs-on указывает рабочему процессу, какой исполнитель использовать при запуске задания. В этом примере рабочий процесс выполняется в операционной системе Ubuntu, которая поступает из пула исполнителей, размещенных на GitHub.
  • steps перечисляет последовательность шагов, выполняемых в задании. Пример YAML состоит из двух шагов. Оба шага выполняют простой скрипт, чтобы вывести текст. Каждый шаг имеет значение name, которое доступно для чтения человеком. Вы увидите имя в журналах рабочего процесса. Чтобы создать шаг сценария с несколькими строками, используйте символ канала (|), как показано в примере. После выполнения шага вы увидите выходные данные в журнале рабочего процесса.

Важный

В файлах YAML отступ важен. Ознакомьтесь с примером YAML. Некоторые строки YAML имеют отступ в два или четыре пробела. Если вы неправильно форматируете отступы в файле, GitHub Actions не сможет его интерпретировать. Visual Studio Code помогает находить и исправлять ошибки в отступах файлов YAML.