Triggering a workflow

About workflow triggers

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

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

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

Workflow triggers are defined with the on key. For more information, see Синтаксис рабочего процесса для GitHub Actions.

The following steps occur to trigger a workflow run:

1. An event occurs on your repository. The event has an associated commit SHA and Git ref.

2. GitHub searches the .github/workflows directory in the root of your repository for workflow files that are present in the associated commit SHA or Git ref of the event.

3. A workflow run is triggered for any workflows that have on: values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run.

   Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, GitHub sets the GITHUB_SHA (commit SHA) and GITHUB_REF (Git ref) environment variables in the runner environment. For more information, see Store information in variables.

Triggering a workflow from a workflow

При использовании репозитория GITHUB_TOKEN для выполнения задач события, запускаемые с помощью GITHUB_TOKEN,за исключением workflow_dispatch и repository_dispatchне будут создавать новый рабочий процесс. Это предотвращает случайное создание рекурсивных запусков рабочих процессов. Например, если при запуске рабочего процесса выполняется передача кода с помощью GITHUB_TOKEN репозитория, новый рабочий процесс не будет запущен, даже если репозиторий содержит рабочий процесс, настроенный для запуска при наступлении события push. For more information, see Automatic token authentication.

If you do want to trigger a workflow from within a workflow run, you can use a GitHub App installation access token or a personal access token instead of GITHUB_TOKEN to trigger events that require a token.

If you use a GitHub App, you'll need to create a GitHub App and store the app ID and private key as secrets. For more information, see Выполнение запросов API с проверкой подлинности с помощью приложения GitHub в рабочем процессе GitHub Actions. If you use a personal access token, you'll need to create a personal access token and store it as a secret. For more information about creating a personal access token, see Управление личными маркерами доступа. For more information about storing secrets, see Using secrets in GitHub Actions.

To minimize your GitHub Actions usage costs, ensure that you don't create recursive or unintended workflow runs.

For example, the following workflow uses a personal access token (stored as a secret called MY_TOKEN) to add a label to an issue via GitHub CLI. Any workflows that run when a label is added will run once this step is performed.

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"

Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

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"

Using events to trigger workflows

Use the on key to specify what events trigger your workflow. For more information about events you can use, see События, инициирующие рабочие процессы.

Using a single event

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

on: push

Using multiple events

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

on: [push, fork]

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

Using activity types and filters with multiple events

You can use activity types and filters to further control when your workflow will run. For more information, see Using event activity types and Using filters. Если вы указываете типы действий или фильтры для события и триггеры рабочего процесса для нескольких событий, необходимо настроить каждое событие отдельно. Необходимо добавить двоеточие (:) ко всем событиям, включая события без конфигурации.

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

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

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

Using event activity types

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

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

on:
  label:
    types:
      - created

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

on:
  issues:
    types:
      - opened
      - labeled

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

Using filters

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

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

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

Using filters to target specific branches for pull request events

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

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

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

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

Example: Including branches

Шаблоны, определенные в 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 и Skipping workflow runs](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging).

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

Example: Excluding branches

В случае соответствия шаблона 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'

Example: Including and excluding branches

Нельзя использовать 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'

Using filters to target specific branches or tags for push events

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

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

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

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

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

Example: Including branches and tags

Шаблоны, определенные в 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.*

Example: Excluding branches and tags

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

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

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

Example: Including and excluding branches and tags

Вы не можете использовать 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'

Using filters to target specific paths for pull request or push events

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

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

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

Ключевые слова paths и paths-ignore принимают стандартные маски, в которых для соответствия нескольким именам путей используются подстановочные знаки * и **. Дополнительные сведения см. в разделе AUTOTITLE.

Example: Including paths

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

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

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

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

Example: Excluding paths

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

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

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

Example: Including and excluding paths

Нельзя использовать 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 diff comparisons

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

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

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

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

Using filters to target specific branches for workflow run events

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

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

Например, рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем 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'

Defining inputs for manually triggered workflows

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

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

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 }} 

Defining inputs, outputs, and secrets for reusable workflows

You can define inputs and secrets that a reusable workflow should receive from a calling workflow. You can also specify outputs that a reusable workflow will make available to a calling workflow. For more information, see Reusing workflows.

Using event information

Information about the event that triggered a workflow run is available in the github.event context. The properties in the github.event context depend on the type of event that triggered the workflow. For example, a workflow triggered when an issue is labeled would have information about the issue and label.

Viewing all properties of an event

Reference the webhook event documentation for common properties and example payloads. For more information, see События и полезные данные веб-перехватчика.

You can also print the entire github.event context to see what properties are available for the event that triggered your workflow:

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

Accessing and using event properties

You can use the github.event context in your workflow. For example, the following workflow runs when a pull request that changes package*.json, .github/CODEOWNERS, or .github/workflows/** is opened. If the pull request author (github.event.pull_request.user.login) is not octobot or dependabot[bot], then the workflow uses the GitHub CLI to label and comment on the pull request (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.'

For more information about contexts, see Доступ к контекстной информации о запусках рабочих процессов. For more information about event payloads, see События и полезные данные веб-перехватчика.

Further controlling how your workflow will run

If you want more granular control than events, event activity types, or event filters provide, you can use conditionals and environments to control whether individual jobs or steps in your workflow will run.

Using conditionals

You can use conditionals to further control whether jobs or steps in your workflow will run.

Example using a value in the event payload

For example, if you want the workflow to run when a specific label is added to an issue, you can trigger on the issues labeled event activity type and use a conditional to check what label triggered the workflow. The following workflow will run when any label is added to an issue in the workflow's repository, but the run_if_label_matches job will only execute if the label is named 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'

Example using event type

For example, if you want to run different jobs or steps depending on what event triggered the workflow, you can use a conditional to check whether a specific event type exists in the event context. The following workflow will run whenever an issue or pull request is closed. If the workflow ran because an issue was closed, the github.event context will contain a value for issue but not for pull_request. Therefore, the if_issue step will run but the if_pr step will not run. Conversely, if the workflow ran because a pull request was closed, the if_pr step will run but the if_issue step will not run.

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

For more information about what information is available in the event context, see Using event information. For more information about how to use conditionals, see Оценка выражений в рабочих процессах и действиях.

Using environments to manually trigger workflow jobs

If you want to manually trigger a specific job in a workflow, you can use an environment that requires approval from a specific team or user. First, configure an environment with required reviewers. For more information, see Managing environments for deployment. Then, reference the environment name in a job in your workflow using the environment: key. Any job referencing the environment will not run until at least one reviewer approves the job.

For example, the following workflow will run whenever there is a push to main. The build job will always run. The publish job will only run after the build job successfully completes (due to needs: [build]) and after all of the rules (including required reviewers) for the environment called production pass (due to environment: production).

on:
  push:
    branches:
      - main

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

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

Available events

For a full list of available events, see События, инициирующие рабочие процессы.