Skip to main content

Общие сведения о GitHub Actions

Изучите основы GitHub Actions, включая основные понятия и основную терминологию.

Обзор

GitHub Actions — это платформа непрерывной интеграции и непрерывной поставки (CI/CD), которая позволяет автоматизировать конвейер сборки, тестирования и развертывания. Вы можете создавать рабочие процессы для построения и тестирования каждого запроса на вытягивание в репозиторий или развертывания объединенных запросов на вытягивание в рабочую среду.

GitHub Actions выходит за рамки только DevOps и позволяет запускать рабочие процессы, когда в репозитории происходят определенные события. Например, можно запустить рабочий процесс для автоматического добавления соответствующих меток, когда кто-то создает проблему в репозитории.

GitHub предоставляет виртуальные машины Linux, Windows и macOS для выполнения рабочих процессов, либо вы можете разместить собственные локальные средства выполнения в собственном центре обработки данных или облачной инфраструктуре.

Дополнительные сведения о вводе GitHub Actions в вашей организации см. в разделе "Внедрение GitHub Actions на предприятии".

Компоненты GitHub Actions

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

Схема триггера события Runner 1 для запуска задания 1, которая активирует Runner 2 для запуска задания 2. Каждая из заданий разбивается на несколько шагов.

Рабочие процессы

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

Рабочие процессы определяются в каталоге .github/workflows в репозитории, а репозиторий может иметь несколько рабочих процессов, каждый из которых может выполнять разные наборы задач. Например, у вас может быть один рабочий процесс для создания и тестирования запросов на вытягивание, другой рабочий процесс — для развертывания приложения при каждом создании выпуска, а также еще один рабочий процесс, добавляющий метку каждый раз, когда кто-то открывает новую проблему.

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

Дополнительные сведения о рабочих процессах см. в разделе "Использование рабочих процессов".

События

Событие — это определенное действие в репозитории, которое активирует выполнение рабочего процесса. Например, источником действия может быть GitHub, когда кто-то создает запрос на вытягивание, открывает проблему или отправляет фиксацию в репозиторий. Вы также можете активировать рабочий процесс для запуска по расписанию, разместив в REST API или вручную.

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

Работы

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

Можно настроить зависимости задания от других заданий. По умолчанию задания не имеют зависимостей и выполняются параллельно друг с другом. Когда задание становится зависимым от другого задания, оно будет ждать завершения зависимого задания, прежде чем сможет начать выполнение. Например, у вас может быть несколько заданий сборки для различных архитектур без зависимостей, а также задание упаковки, зависящее от этих заданий. Задания сборки будут выполняться параллельно, а когда все они успешно завершатся, будет запущено задание упаковки.

Дополнительные сведения о заданиях см. в разделе "Использование заданий".

Действия

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

Можно написать собственные действия или найти действия для использования в рабочих процессах в GitHub Marketplace.

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

Дополнительные сведения см. в разделе Создание действий.

Средства выполнения

Средство выполнения тестов — это сервер, на котором выполняются рабочие процессы при их активации.Каждое средство выполнения может выполнять одно задание за раз. GitHub предоставляет средства выполнения Ubuntu Linux, Microsoft Windows и macOS для выполнения рабочих процессов. Каждый рабочий процесс выполняется на новой подготовленной виртуальной машине. GitHub также предлагает крупное средство выполнения, которые доступны в более крупных конфигурациях. Дополнительные сведения см. в разделе О более крупных бегунах. Если вам нужна другая операционная система или требуется определенная конфигурация оборудования, можно разместить собственные средства выполнения. Дополнительные сведения о локальных бегунахсм. в разделе "Размещение собственных средств выполнения".

Создание примера рабочего процесса

Для определения рабочего процесса GitHub Actions использует синтаксис YAML. Каждый рабочий процесс хранится как отдельный YAML-файл в репозитории кода в каталоге с именем .github/workflows.

Можно создать пример рабочего процесса в репозитории, который автоматически активирует ряд команд при отправке кода. В этом рабочем процессе GitHub Actions извлекает отправленный код, устанавливает платформу тестирования bats и выполняет базовую команду для вывода версии bats: bats -v.

  1. В репозитории создайте каталог .github/workflows/ для хранения файлов рабочего процесса.

  2. В каталоге .github/workflows/ создайте файл с именем learn-github-actions.yml и добавьте следующий код.

    YAML
    name: learn-github-actions
    run-name: ${{ github.actor }} is learning GitHub Actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v4
          - uses: actions/setup-node@v4
            with:
              node-version: '14'
          - run: npm install -g bats
          - run: bats -v
    
  3. Зафиксируйте эти изменения и отправьте их в репозиторий GitHub.

Новый файл рабочего процесса GitHub Actions теперь установлен в репозитории и будет выполняться автоматически каждый раз, когда кто-то отправляет изменения в репозиторий. Дополнительные сведения о журнале выполнения рабочего процесса см. в разделе "Просмотр действия для выполнения рабочего процесса".

Общие сведения о файле рабочего процесса

Чтобы понять, как используется синтаксис YAML для создания файла рабочего процесса, просмотрите объяснение каждой строки вводного примера.

YAML
name: learn-github-actions

Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.

run-name: ${{ github.actor }} is learning GitHub Actions

Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the github context to display the username of the actor that triggered the workflow run. For more information, see "Синтаксис рабочего процесса для GitHub Actions."

on: [push]

Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Синтаксис рабочего процесса для GitHub Actions."

jobs:

Groups together all the jobs that run in the learn-github-actions workflow.

  check-bats-version:

Defines a job named check-bats-version. The child keys will define properties of the job.

    runs-on: ubuntu-latest

Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "Синтаксис рабочего процесса для GitHub Actions"

    steps:

Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell script.

      - uses: actions/checkout@v4

The uses keyword specifies that this step will run v4 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.

      - uses: actions/setup-node@v4
        with:
          node-version: '14'

This step uses the actions/setup-node@v4 action to install the specified version of the Node.js. (This example uses version 14.) This puts both the node and npm commands in your PATH.

      - run: npm install -g bats

The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the bats software testing package.

      - run: bats -v

Finally, you'll run the bats command with a parameter that outputs the software version.

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions
# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '14'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

Визуализация файла рабочего процесса

На этой схеме показан только что созданный файл рабочего процесса и порядок организации компонентов GitHub Actions в иерархии. Каждый этап выполняет одно действие или скрипт оболочки. Этапы 1 и 2 выполняют действия, а этапы 3 и 4 выполняют скрипты оболочки. Дополнительные предварительно созданные действия для рабочих процессов см. в разделе "Поиск и настройка действий".

Схема, показывающая триггер, средство выполнения и задание рабочего процесса. Задание разбито на 4 шага.

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

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

  1. На GitHub.comперейдите на главную страницу репозитория.

  2. Под именем репозитория щелкните Actions.

    Снимок экрана: вкладки для репозитория github/docs. Вкладка "Действия" выделена оранжевым контуром.

  3. На левой боковой панели щелкните нужный рабочий процесс.

    Снимок экрана: левая боковая панель вкладки "Действия". Рабочий процесс CodeQL описывается в темно-оранжевый цвет.

  4. В списке запусков рабочего процесса щелкните имя запуска, чтобы просмотреть сводку по выполнению рабочего процесса.

  5. На левой боковой панели или в графе визуализации щелкните задание, которое нужно просмотреть.

  6. Чтобы просмотреть результаты шага, щелкните этот шаг.

Следующие шаги

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

  • Быстрый способ создания рабочего процесса GitHub Actions см. в разделе "Использование начальных рабочих процессов".
  • Рабочие процессы непрерывной интеграции (CI) для создания и тестирования кода см. в разделе "Автоматизация сборок и тестов".
  • Сведения о создании и публикации пакетов см. в разделе "Публикация пакетов".
  • Сведения о развертывании проектов см. в разделе "Развертывание".
  • Сведения об автоматизации задач и процессов в GitHubсм. в разделе "Управление проблемами и запросами на вытягивание".
  • Примеры, демонстрирующие более сложные функции GitHub Actions, включая многие из приведенных выше вариантов использования, см. в разделе "Примеры". Подробные примеры, объясняющие, как протестировать код в средстве выполнения, получить доступ к GitHub CLI и использовать дополнительные функции, такие как параллелизм и матрицы тестов.
  • Если вы хотите сертифицировать навыки в автоматизации рабочих процессов и ускорить разработку с помощью GitHub Actions, вы можете заработать сертификат GitHub Actions с помощью GitHub Certifications. Дополнительные сведения см. в разделе "О GitHub Certifications".

Дополнительные материалы