Активация рабочего процесса

Сведения о триггерах рабочих процессов

Триггеры рабочего процесса — это события, которые приводят к запуску рабочего процесса. Эти события могут быть следующими:

• События, происходящие в репозитории рабочего процесса
• События, происходящие за пределами GitHub Enterprise Server и запускающие событие repository_dispatch в GitHub Enterprise Server
• Запланированное время
• Руководство

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

Триггеры рабочих процессов определяются с помощью ключа on. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Чтобы запустить рабочий процесс, выполните следующие действия:

1. Событие происходит в репозитории. Событие имеет связанную фиксацию SHA и ссылку Git.

2. GitHub Enterprise Server выполняет поиск .github/workflows каталога в корневом каталоге репозитория для файлов рабочих процессов, присутствующих в связанной фиксации SHA или Git ref события.

3. Запуск рабочего процесса выполняется для всех рабочих процессов со значениями on:, соответствующими событию активации. Для некоторых событий также требуется, чтобы файл рабочего процесса присутствовал в ветви репозитория по умолчанию.

   Каждый запуск рабочего процесса будет использовать версию рабочего процесса, которая присутствует в связанной фиксации SHA или ссылке Git события. При запуске рабочего процесса GitHub Enterprise Server задает переменные среды GITHUB_SHA (фиксация SHA) и GITHUB_REF (ссылка Git) в среде средства выполнения. Дополнительные сведения см. в разделе Хранение сведений в переменных.

Активация рабочего процесса из рабочего процесса

Если вы выполняете задачи с помощью GITHUB_TOKEN репозитория, события, активированные GITHUB_TOKEN, за исключением workflow_dispatch и repository_dispatch, не создадут новый запуск рабочего процесса. Это предотвращает случайное создание рекурсивных запусков рабочих процессов. Например, если при запуске рабочего процесса выполняется передача кода с помощью GITHUB_TOKEN репозитория, новый рабочий процесс не будет запущен, даже если репозиторий содержит рабочий процесс, настроенный для запуска при наступлении события push. Дополнительные сведения см. в разделе "Автоматическая проверка подлинности токенов".

Если вы хотите активировать рабочий процесс в рамках выполнения рабочего процесса, можно использовать маркер доступа к установке GitHub App или personal access token вместо GITHUB_TOKEN активации событий, требующих маркера.

Если вы используете GitHub App, необходимо создать GitHub App и сохранить идентификатор приложения и закрытый ключ в виде секретов. Дополнительные сведения см. в разделе Выполнение запросов API с проверкой подлинности с помощью приложения GitHub в рабочем процессе GitHub Actions. Если вы используете personal access token, необходимо создать personal access token и сохранить его в виде секрета. Дополнительные сведения о создании personal access tokenсм. в разделе "Управление личными маркерами доступа". Дополнительные сведения о хранении секретов см. в разделе "Использование секретов в GitHub Actions".

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

Например, следующий рабочий процесс использует personal access token (хранящийся в виде секрета MY_TOKEN) для добавления метки в проблему с помощью GitHub CLI. Все рабочие процессы, выполняемые при добавлении метки, будут выполняться после выполнения этого шага.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.MY_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

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

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

Использование событий для активации рабочих процессов

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

Использование одного события

Например, рабочий процесс со следующим значением on будет выполняться при осуществлении отправки в любую ветвь в репозитории рабочего процесса:

on: push

Использование нескольких событий

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

on: [push, fork]

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

Использование типов действий и фильтров с несколькими событиями

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

Например, рабочий процесс со следующим значением on будет выполняться в следующих случаях:

• создание метки;
• отправка в ветвь main в репозитории;
• отправка в ветвь с поддержкой GitHub Pages.

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

Использование типов действий событий

Некоторые события имеют типы действий, позволяющие лучше контролировать выполнение рабочего процесса. Используйте on.<event_name>.types для определения типа действия для события, которое активирует запуск рабочего процесса.

Например, событие issue_comment имеет типы действий created, edited и deleted. Если рабочий процесс активируется в событии label, он будет выполняться при создании, изменении или удалении метки. Если указать тип действия created для события label, рабочий процесс будет запускаться при создании метки, но не при изменении или удалении метки.

on:
  label:
    types:
      - created

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

on:
  issues:
    types:
      - opened
      - labeled

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

Использование фильтров

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

Например, событие push имеет фильтр branches, из-за которого рабочий процесс выполняется только при отправке в ветвь, которая соответствует фильтру branches, а не при любой отправке.

on:
  push:
    branches:
      - main
      - 'releases/**'

Использование фильтров для назначения определенных ветвей для событий запроса на вытягивание

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

Используйте фильтр branches, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр branches-ignore, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры branches и branches-ignore одновременно.

Если вы определили и branches/branches-ignore, и paths/paths-ignore, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.

Ключевые слова branches и branches-ignore принимают стандартные маски, использующие такие символы, как *, **, +, ?, ! и другие, чтобы соответствовать нескольким именам ветвей. Если имя содержит любой из этих символов и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \. Дополнительные сведения о шаблонах глобов см. в разделе "Синтаксис рабочего процесса для GitHub Actions".

Пример: включение ветвей

Шаблоны, определенные в branches, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие pull_request для запроса на вытягивание, нацеленного на:

• ветви с именем main (refs/heads/main);
• ветви с именем mona/octocat (refs/heads/mona/octocat);
• ветви, имя которой начинается с releases/, например releases/10 (refs/heads/releases/10);

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'

Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Пропуск запусков рабочих процессов](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging)".

Если рабочий процесс пропускается из-за фильтрации ветвей, фильтрации путей или сообщения фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.

Пример исключения ветвей

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

• ветви с именем mona/octocat (refs/heads/mona/octocat);
• ветви, имя которой соответствует releases/**-alpha, например releases/beta/3-alpha (refs/heads/releases/beta/3-alpha);

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'

Пример: включение и исключение ветвей

Нельзя использовать branches и branches-ignore для фильтрации одного и того же события в одном рабочем процессе. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр branches с символом !, чтобы указать, какие ветви следует исключить.

Если вы определяете ветвь с символом !, необходимо также определить по крайней мере одну ветвь без символа !. Если вы хотите только исключить ветви, используйте вместо этого branches-ignore.

Порядок определения шаблонов имеет значение.

• Соответствующий отрицательный шаблон (с префиксом !) после положительного совпадения исключает ссылку Git.
• Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.

Указанный ниже рабочий процесс будет выполняться на событиях pull_request для запросов на вытягивание, нацеленных на releases/10 или releases/beta/mona, но не для запросов на вытягивание, нацеленных на releases/10-alpha или releases/beta/3-alpha, потому что отрицательный шаблон !releases/**-alpha соответствует положительному шаблону.

on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Использование фильтров для назначения определенных ветвей или тегов для событий отправки

Пример. Включение ветвей и тегов

Шаблоны, определенные в branches и tags, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда событие push происходит в:

• ветви с именем main (refs/heads/main);
• ветви с именем mona/octocat (refs/heads/mona/octocat);
• ветви, имя которой начинается с releases/, например releases/10 (refs/heads/releases/10);
• теге с именем v2 (refs/tags/v2);
• теге, имя которого начинается с v1., например v1.9.1 (refs/tags/v1.9.1).

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:
      - v2
      - v1.*

Пример. Исключение ветвей и тегов

Пример. Включение и исключение ветвей и тегов

Вы не можете использовать branches и branches-ignore для фильтрации одного и того же события в одном рабочем процессе. Аналогично, вы не можете использовать tags и tags-ignore для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите одновременно включить и исключить шаблоны ветвей или тегов для одного события, используйте фильтр branches или tags с символом !, чтобы указать, какие ветви или теги следует исключить.

Если вы определяете ветвь с символом !, необходимо также определить по крайней мере одну ветвь без символа !. Если вы хотите только исключить ветви, используйте вместо этого branches-ignore. Аналогично, если вы определяете тег с символом !, необходимо также определить по крайней мере один тег без символа !. Если вы хотите только исключить теги, используйте вместо этого tags-ignore.

Порядок определения шаблонов имеет значение.

• Соответствующий отрицательный шаблон (с префиксом !) после положительного совпадения исключает ссылку Git.
• Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.

Следующий рабочий процесс будет выполняться при отправке в releases/10 или releases/beta/mona, но не в releases/10-alpha или releases/beta/3-alpha, потому что за положительным шаблоном следует отрицательный шаблон !releases/**-alpha.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Использование фильтров для назначения определенных ветвей для запросов на вытягивание или событий отправки

При использовании событий push и pull_request можно настроить запускаемый рабочий процесс в зависимости от того, какие пути к файлам изменяются. Фильтры путей не оцениваются при отправке тегов.

Используйте фильтр paths, если требуется включить шаблоны путей к файлам или одновременно включить и исключить их. Используйте фильтр paths-ignore, если требуется только исключить шаблоны путей к файлам. Для одного и того же события в рабочем процессе нельзя использовать фильтры paths и paths-ignore одновременно. Если вы хотите включить и исключить шаблоны путей для одного события, используйте paths префикс фильтра с ! символом, чтобы указать, какие пути следует исключить.

Если вы определили и branches/branches-ignore, и paths/paths-ignore, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.

Ключевые слова paths и paths-ignore принимают стандартные маски, в которых для соответствия нескольким именам путей используются подстановочные знаки * и **. Дополнительные сведения см. в разделе "Синтаксис рабочего процесса для GitHub Actions".

Пример. Включение путей

Если хотя бы один путь соответствует шаблону в фильтре paths, рабочий процесс запускается. Например, приведенный ниже рабочий процесс будет выполняться при каждой отправке файла JavaScript (.js).

on:
  push:
    paths:
      - '**.js'

Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Пропуск запусков рабочих процессов](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging)".

Если рабочий процесс пропускается из-за фильтрации путей, фильтрации ветвей или сообщения фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.

Пример. Исключение путей

Если все имена путей соответствуют шаблонам в paths-ignore, рабочий процесс не запускается. Если хотя бы одно имя пути не соответствует шаблонам в paths-ignore, рабочий процесс запускается.

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

on:
  push:
    paths-ignore:
      - 'docs/**'

Пример. Включение и исключение путей

Нельзя использовать paths и paths-ignore для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны путей для одного события, используйте paths префикс фильтра с ! символом, чтобы указать, какие пути следует исключить.

Если вы определяете путь с символом !, необходимо также определить по крайней мере один путь без символа !. Если вы хотите только исключить пути, используйте вместо этого paths-ignore.

Порядок определения paths шаблонов имеет значение:

• Соответствующий отрицательный шаблон (с префиксом !) после положительного совпадения исключает путь.
• Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.

Этот пример запускается каждый раз, когда событие push включает файл в каталоге sub-project или его подкаталогах, но не в каталоге sub-project/docs. Например, принудительная отправка с изменением sub-project/index.js или sub-project/src/index.js запустит выполнение рабочего процесса, но принудительная отправка, изменяющая только sub-project/docs/readme.md, не запустит его.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Сравнение различий в GIT

Фильтр определяет, должен ли запускаться рабочий процесс, оценивая измененные файлы и проверяя их по списку paths-ignore или paths. Если измененных файлов нет, рабочий процесс не запускается.

GitHub создает список измененных файлов, используя различия с двумя точками для push-уведомлений и с тремя точками — для запросов на вытягивание.

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

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

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

Использование фильтров для назначения определенных ветвей для событий выполнения рабочего процесса

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

В фильтрах branches и branches-ignore можно использовать стандартные маски с такими символами, как *, **, +, ?, ! и другие, для сопоставления нескольких имен ветвей. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью \. Дополнительные сведения о шаблонах глобов см. в разделе "Синтаксис рабочего процесса для GitHub Actions".

Например, рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем Build выполняется в ветви, имя которой начинается с releases/.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

Рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем Build выполняется в ветви с именем отличным от canary.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

Для одного и того же события в рабочем процессе нельзя использовать фильтры branches и branches-ignore одновременно. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр branches с символом !, чтобы указать, какие ветви следует исключить.

Порядок определения шаблонов имеет значение.

• Если после включающего шаблона идет исключающий (с префиксом !) и найдена ветвь, соответствующая им обоим, такая ветвь исключается.
• Если после исключающего шаблона идет включающий, ветвь, соответствующая им обоим, снова включается.

Например, рабочий процесс со следующим триггером будет выполняться, если рабочий процесс с именем Build выполняется в ветви с именем releases/10 или releases/beta/mona, но не в ветви releases/10-alpha, releases/beta/3-alpha или main.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Определение входных данных для рабочих процессов, активированных вручную

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

Этот триггер получает события только в том случае, если файл рабочего процесса находится на ветвь по умолчанию. Активированный рабочий процесс получает входные данные в контексте inputs. Дополнительные сведения см. в статье Контексты.

```yaml on: workflow_dispatch: inputs: logLevel: description: 'Log level' required: true default: 'warning' type: choice options: - info - warning - debug print_tags: description: 'True to print to STDOUT' required: true type: boolean tags: description: 'Test scenario tags' required: true type: string environment: description: 'Environment to run tests against' type: environment required: true

jobs: print-tag: runs-on: ubuntu-latest if: ${{ inputs.print_tags }} steps: - name: Print the input tag to STDOUT run: echo The tags are ${{ inputs.tags }}

## Определение входных, выходных данных и секретов для повторно используемых рабочих процессов

Вы можете определить входные данные и секреты, которые рабочий процесс, доступный для повторного использования, должен получать от вызывающего рабочего процесса. Вы также можете указать выходные данные, которые повторно используемый рабочий процесс сделает доступным для вызывающего рабочего процесса. Дополнительные сведения см. в разделе [AUTOTITLE](/actions/using-workflows/reusing-workflows).

## Использование сведений о событии

Сведения о событии, которое активировало рабочий процесс, доступны в контексте `github.event`. Свойства в контексте `github.event` зависят от типа события, которое активировало рабочий процесс. Например, рабочий процесс, запускаемый при присвоении метки проблеме, будет содержать сведения о проблеме и метке.

### Просмотр всех свойств события

Обратитесь к документации по событиям веб-перехватчиков, чтобы ознакомиться с общими свойствами и примерами полезных данных. Дополнительные сведения см. в разделе [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads).

Вы также можете распечатать весь контекст `github.event`, чтобы узнать, какие свойства доступны для события, которое активировало рабочий процесс:

```yaml
jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT

Доступ к свойствам события и их использование

Вы можете использовать контекст github.event в своем рабочем процессе. Например, следующий рабочий процесс выполняется при открытии запроса на вытягивание, который изменяет package*.json, .github/CODEOWNERS или .github/workflows/**. Если автор запроса на вытягивание (github.event.pull_request.user.login) не является octobot или dependabot[bot], рабочий процесс использует GitHub CLI для добавления меток и комментариев к запросу на вытягивание (github.event.pull_request.number).

on:
  pull_request:
    types:
      - opened
    paths:
      - '.github/workflows/**'
      - '.github/CODEOWNERS'
      - 'package*.json'

jobs:
  triage:
    if: >-
      github.event.pull_request.user.login != 'octobot' &&
      github.event.pull_request.user.login != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: "Comment about changes we can't accept"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.html_url }}
        run: |
          gh pr edit $PR --add-label 'invalid'
          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'

Дополнительные сведения о контекстах см. в разделе "Доступ к контекстной информации о запусках рабочих процессов". Дополнительные сведения о полезных данных событий см. в разделе "События и полезные данные веб-перехватчика".

Дальнейшее управление запуском рабочего процесса

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

Использование условных выражений

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

Пример использования значения в полезных данных события

Например, если требуется, чтобы рабочий процесс выполнялся при добавлении определенной метки в проблему, можно активировать тип действия события issues labeled и использовать условное выражение для проверки того, какая метка активировала рабочий процесс. Следующий рабочий процесс будет выполняться при добавлении метки в проблему в репозитории рабочего процесса, но задание run_if_label_matches будет выполняться только в том случае, если метка называется bug.

on:
  issues:
    types:
      - labeled

jobs:
  run_if_label_matches:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    steps:
      - run: echo 'The label was bug'

Пример использования типа события

Например, если вы хотите выполнять различные задания или шаги в зависимости от того, какое событие активировало рабочий процесс, можно использовать условное выражение, чтобы проверить, существует ли определенный тип события в контексте события. Следующий рабочий процесс будет выполняться при закрытии проблемы или запроса на вытягивание. Если рабочий процесс были выполнен по причине закрытия проблемы, контекст github.event будет содержать значение для issue, но не для pull_request. Поэтому шаг if_issue будет выполняться, а шаг if_pr не будет выполняться. Если рабочий процесс были выполнен по причине закрытия запроса на вытягивание,шаг if_pr будет выполняться, а шаг if_issue — нет.

on:
  issues:
    types:
      - closed
  pull_request:
    types:
      - closed

jobs:
  state_event_type:
    runs-on: ubuntu-latest
    steps:
    - name: if_issue
      if: github.event.issue
      run: |
        echo An issue was closed
    - name: if_pr
      if: github.event.pull_request
      run: |
        echo A pull request was closed

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

Использование сред для активации заданий рабочих процессов вручную

Если вы хотите вручную активировать определенное задание в рабочем процессе, можно использовать среду, требующую утверждения от определенной команды или пользователя. Сначала настройте среду с необходимыми рецензентами. Дополнительные сведения см. в разделе Управление средами для развертывания. Затем укажите имя среды в задании в рабочем процессе с помощью ключа environment:. Любое задание, ссылающееся на среду, не будет выполняться, пока хотя бы один рецензент не утвердит задание.

Например, следующий рабочий процесс будет выполняться всякий раз, когда выполняется отправка в главную ветвь. Задание build будет выполняться всегда. Задание publish будет выполняться только после успешного завершения задания build (ввиду needs: [build]) и после соблюдения требований всех правил (включая обязательных рецензентов) для среды, называемой production (ввиду environment: production).

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        echo 'building'

  publish:
    needs: [build]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: publish
        echo 'publishing'

Доступные события

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