События, инициирующие рабочие процессы

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

Триггеры рабочего процесса — это события, которые приводят к запуску рабочего процесса. Дополнительные сведения об использовании триггеров рабочего процесса см. в разделе Активация рабочего процесса.

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

branch_protection_rule

Это событие запускает рабочий процесс при изменении правил защиты ветви в репозитории рабочих процессов. Дополнительные сведения о правилах защиты ветвей см. в разделе Сведения о защищенных ветвях. Сведения об API правил защиты ветвей см. в разделе Объекты в документации по API GraphQL или Ветви в документации по REST API.

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

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

Это событие запускает рабочий процесс при действии, связанном с выполнением проверки. Выполнение проверки — это отдельный тест, входящий в состав набора проверок. Дополнительные сведения см. в разделе Использование REST API для взаимодействия с проверками. Сведения о проверка запуска API см. в разделе Объекты документации по API GraphQL или Проверки в документации по REST API.

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

on:
  check_run:
    types: [rerequested, completed]

check_suite

Это событие запускает рабочий процесс при выполнении действий, связанных с набором проверок. Набор проверок — это коллекция запусков проверок, созданных для определенной фиксации. Набор проверок позволяет получить общее заключение о состоянии выполнения проверок, входящих в состав набора. Дополнительные сведения см. в разделе Использование REST API для взаимодействия с проверками. Сведения об API набора проверка см. в разделе Объекты в документации по API GraphQL или Проверки в документации по REST API.

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

on:
  check_suite:
    types: [completed]

create

Это событие запускает рабочий процесс при создании ссылки на Git (ветвь или тег Git) из репозитория рабочего процесса. Сведения об API для создания справочника по Git см. в разделе Изменения в документации по API GraphQL или База данных Git в документации по REST API.

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

on:
  create

delete

Это событие запускает рабочий процесс при удалении ссылки на Git (ветвь или тег Git) из репозитория рабочего процесса. Сведения об API для удаления ссылки на Git см. в разделе Изменения в документации по API GraphQL или База данных Git в документации по REST API.

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

on:
  delete

deployment

Это событие запускает рабочий процесс при создании развертывания в репозитории рабочего процесса. Развертывания, созданные с помощью SHA фиксации, могут не иметь ссылки на Git. Сведения об API для создания развертывания см. в разделе Изменения документации по API GraphQL или Репозитории в документации по REST API.

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

on:
  deployment

deployment_status

Это событие запускает рабочий процесс, когда состояние развертывания предоставляется третьей стороной. Развертывания, созданные с помощью SHA фиксации, могут не иметь ссылки на Git. Сведения об API для создания состояния развертывания см. в разделе Изменения в документации по API GraphQL или Развернутые приложения в документации по REST API.

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

on:
  deployment_status

discussion

Это событие запускает рабочий процесс при создании или изменении обсуждения в репозитории рабочего процесса. Для действий, связанных с комментариями к обсуждению, используйте событие discussion_comment. Дополнительные сведения об обсуждениях см. в разделе Сведения об обсуждениях. Сведения об API GraphQL см. в разделе Объекты.

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

on:
  discussion:
    types: [created, edited, answered]

discussion_comment

Это событие запускает рабочий процесс при создании или изменении комментария к обсуждению в репозитории рабочего процесса. Для действий, связанных с обсуждением, а не с комментариями к нему, используйте событие discussion. Дополнительные сведения об обсуждениях см. в разделе Сведения об обсуждениях. Сведения об API GraphQL см. в разделе Объекты.

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

on:
  discussion_comment:
    types: [created, deleted]

fork

Это событие запускает рабочий процесс при создании вилки репозитория. Дополнительные сведения о REST API см. в разделе Репозитории.

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

on:
  fork

gollum

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

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

on:
  gollum

issue_comment

Это событие запускает рабочий процесс при создании, изменении или удалении комментария к проблеме или запросу на вытягивание. Сведения об API комментариев о проблеме см. в разделе Объекты в документации по API GraphQL или События и полезные данные веб-перехватчика в документации по REST API.

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

on:
  issue_comment:
    types: [created, deleted]

issue_comment только для проблем или только для запросов на вытягивание

Событие issue_comment возникает как для комментариев к проблемам, так и для комментариев к запросам на вытягивание. Свойство github.event.issue.pull_request можно использовать в условном режиме для выполнения различных действий в зависимости от того, был ли объект-триггер проблемой или запросом на вытягивание.

Например, этот рабочий процесс будет выполнять задание pr_commented, только если событие issue_comment возникло из запроса на вытягивание. Этот рабочий процесс будет запускать задание issue_commented, только если событие issue_comment возникло из проблемы.

on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on PR $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on issue $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

issues

Это событие запускает рабочий процесс при создании или изменении проблемы в репозитории рабочего процесса. Для действий, связанных с комментариями к проблеме, используйте событие issue_comment. Дополнительные сведения о проблемах см. в разделе О проблемах. Сведения о проблемных API см. в разделе Объекты в документации по API GraphQL или Проблемы в документации по REST API.

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

on:
  issues:
    types: [opened, edited, milestoned]

label

Это событие запускает рабочий процесс при создании или изменении метки в репозитории рабочего процесса. Дополнительные сведения о метках см. в разделе Управление метками. Сведения об API меток см. в разделе Объекты в документации по API GraphQL или Проблемы в документации по REST API.

Чтобы запустить рабочий процесс при добавлении метки в проблему, запрос на вытягивание или обсуждение либо при удалении метки, используйте типы действий labeled или unlabeled для событий issues, pull_request, pull_request_target или discussion.

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

on:
  label:
    types: [created, deleted]

milestone

Это событие запускает рабочий процесс при создании или изменении вехи в репозитории рабочего процесса. Дополнительные сведения о вехах см. в разделе Сведения о вехах. Сведения об API-интерфейсах вех см. в разделе Объекты в документации по API GraphQL или autoTITLE в документации по REST API.

Чтобы запустить рабочий процесс при добавлении проблемы в веху или ее удалении из вехи, используйте тип действия milestoned или demilestoned для события issues.

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

on:
  milestone:
    types: [opened, deleted]

page_build

Это событие запускает рабочий процесс, когда выполняется отправка в ветвь, которая является источником публикации для GitHub Pages, если для репозитория включена служба GitHub Pages. Дополнительные сведения об источниках публикации GitHub Pages см. в разделе Настройка источника публикации для сайта GitHub Pages. Сведения о REST API см. в разделе Репозитории.

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

on:
  page_build

project

Это событие запускает рабочий процесс при создании или изменении доски проекта. Для действий, связанных с карточками или столбцами на доске проекта, используйте событие project_card или project_column. Дополнительные сведения о досках проектов см. в разделе Сведения о project boards. Сведения о доска проекта API см. в разделе "Объекты" документации по API GraphQL или "Project boards" в документации по REST API.

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

on:
  project:
    types: [created, deleted]

project_card

Это событие запускает рабочий процесс при создании или изменении карточки на доске проекта. Для действий, связанных с досками проектов или столбцами на доске проекта, используйте событие project или project_column. Дополнительные сведения о досках проектов см. в разделе Сведения о project boards. Сведения о проекте карта API см. в разделе Объекты в документации по API GraphQL или autoTITLE в документации по REST API.

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

on:
  project_card:
    types: [created, deleted]

project_column

Это событие запускает рабочий процесс при создании или изменении столбца на доске проекта. Для действий, связанных с досками проектов или карточками на доске проекта, используйте событие project или project_card. Дополнительные сведения о досках проектов см. в разделе Сведения о project boards. Сведения об API столбцов проекта см. в разделе Объекты в документации по API GraphQL или autoTITLE в документации по REST API.

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

on:
  project_column:
    types: [created, deleted]

public

Это событие запускает рабочий процесс при изменении репозитория рабочего процесса с частного на общедоступный. Дополнительные сведения о REST API см. в разделе Репозитории.

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

on:
  public

pull_request

Это событие запускает рабочий процесс при выполнении действия по запросу на вытягивание в репозитории рабочего процесса. Например, если типы действий не указаны, рабочий процесс запускается при открытии или повторном открытии запроса на вытягивание либо при обновлении главной ветви запроса на вытягивание. Для действий, связанных с проверкой запросов на вытягивание, комментариями к проверкам запросов на вытягивание или комментариями к запросам на вытягивание, используйте событие pull_request_review, pull_request_review_comment или issue_comment. Сведения об API запроса на вытягивание см. в разделе Объекты в документации по API GraphQL или Запросы данных в документации по REST API.

Обратите внимание, что переменная GITHUB_SHA для этого события — это последняя фиксация слияния для ветви слияния запроса на вытягивание. Чтобы получить идентификатор фиксации для последней фиксации в главной ветви запроса на вытягивание, используйте переменную github.event.pull_request.head.sha.

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

on:
  pull_request:
    types: [opened, reopened]

Контекст события можно использовать для дальнейшего управления выполнением заданий в рабочем процессе. Например, этот рабочий процесс будет выполняться при запросе проверки по запросу на вытягивание, но задание specific_review_requested будет выполняться, только если проверка запрошена командой octo-team.

on:
  pull_request:
    types: [review_requested]
jobs:
  specific_review_requested:
    runs-on: ubuntu-latest
    if: ${{ github.event.requested_team.name == 'octo-team'}}
    steps:
      - run: echo 'A review from octo-team was requested'

pull_request Выполнение рабочего процесса на основе головы или базовая ветвь запроса на вытягивание

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

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

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Чтобы выполнить задание на основе имени главной ветви запроса на вытягивание (в отличие от имени базовой ветви запроса на вытягивание), используйте контекст github.head_ref в условном режиме. Например, этот рабочий процесс будет выполняться при каждом открытии запроса на вытягивание, но задание run_if будет выполняться только в том случае, если заголовок запроса на вытягивание является ветвью, имя которой начинается с releases/:

on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

pull_request Запуск рабочего процесса на основе файлов, измененных в запросе на вытягивание

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

Например, этот рабочий процесс будет выполняться, когда в запросе на вытягивание изменен файл JavaScript (.js):

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

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

pull_request Запуск рабочего процесса при слиянии запроса на вытягивание

При слиянии запрос на вытягивание автоматически закрывается. Чтобы запустить рабочий процесс при слиянии запроса на вытягивание, используйте тип события pull_request closed вместе с условием, проверяющим значение merged события. Например, следующий рабочий процесс будет выполняться при закрытии запроса на вытягивание. Задание if_merged будет выполняться только в том случае, если произошло слияние запроса на вытягивание.

on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

Рабочие процессы в вилках репозиториев

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

За исключением GITHUB_TOKEN, секреты не передаются в средство выполнения при активации рабочего процесса из вилки репозитория. Имеет GITHUB_TOKEN разрешения только для чтения в запросах на вытягивание из вилки репозиториев. Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.

События запросов на вытягивание для вилок репозиториев

Для запросов на вытягивание из вилки репозитория в базовый репозиторий GitHub Enterprise Server отправляет события pull_request, issue_comment, pull_request_review_comment, pull_request_review и pull_request_target в базовый репозиторий. В вилке репозитория никакие события запросов на вытягивание не происходят.

Запросы на вытягивание из вилки репозитория в частный репозиторий выполняются только при включении. См. раздел Управление параметрами GitHub Actions для репозитория.

pull_request_comment (используйте issue_comment)

Чтобы запустить рабочий процесс при создании, изменении или удалении комментария к запросу на вытягивание (а не к разнице запроса на вытягивание), используйте событие issue_comment. Для действий, связанных с проверкой запросов на вытягивание или комментариями к проверкам запросов на вытягивание, используйте событие pull_request_review или pull_request_review_comment.

pull_request_review

Это событие запускает рабочий процесс при отправке, изменении или закрытии проверки запроса на вытягивание. Проверка запроса на вытягивание — это группа комментариев к проверке запроса на вытягивание, дополняющих комментарии к тексту запроса и его состояние. Для действий, связанных с комментариями к проверкам запросов на вытягивание или комментариями к запросам на вытягивание, используйте событие pull_request_review_comment или issue_comment. Сведения о проверка запроса на вытягивание API см. в разделе Объекты в документации по API GraphQL или в разделе AUTOTITLE в документации по REST API.

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

on:
  pull_request_review:
    types: [edited, dismissed]

Запуск рабочего процесса при утверждении запроса на вытягивание

Чтобы запустить рабочий процесс при утверждении запроса на вытягивание, активируйте рабочий процесс, используя тип submitted события pull_request_review, а затем проверьте состояние проверки, используя свойство github.event.review.state. Например, этот рабочий процесс будет выполняться при отправке проверки запроса на вытягивание, однако задание approved будет выполняться, только если отправленная проверка утверждена:

on:
  pull_request_review:
    types: [submitted]

jobs:
  approved:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This PR was approved"

Рабочие процессы в вилках репозиториев

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

За исключением GITHUB_TOKEN, секреты не передаются в средство выполнения при активации рабочего процесса из вилки репозитория. Имеет GITHUB_TOKEN разрешения только для чтения в запросах на вытягивание из вилки репозиториев. Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.

События запросов на вытягивание для вилок репозиториев

Для запросов на вытягивание из вилки репозитория в базовый репозиторий GitHub Enterprise Server отправляет события pull_request, issue_comment, pull_request_review_comment, pull_request_review и pull_request_target в базовый репозиторий. В вилке репозитория никакие события запросов на вытягивание не происходят.

Запросы на вытягивание из вилки репозитория в частный репозиторий выполняются только при включении. См. раздел Управление параметрами GitHub Actions для репозитория.

pull_request_review_comment

Это событие запускает рабочий процесс при изменении комментария к проверке запроса на вытягивание. Комментарий к проверке запроса на вытягивание — это комментарий к разнице запроса на вытягивание. Для действий, связанных с проверкой запросов на вытягивание или комментариями к запросам, используйте событие pull_request_review или issue_comment. Сведения об API комментариев проверка запроса на вытягивание см. в разделе Объекты в документации по API GraphQL или Запросы данных в документации по REST API.

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

on:
  pull_request_review_comment:
    types: [created, deleted]

Рабочие процессы в вилках репозиториев

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

За исключением GITHUB_TOKEN, секреты не передаются в средство выполнения при активации рабочего процесса из вилки репозитория. Имеет GITHUB_TOKEN разрешения только для чтения в запросах на вытягивание из вилки репозиториев. Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.

События запросов на вытягивание для вилок репозиториев

Для запросов на вытягивание из вилки репозитория в базовый репозиторий GitHub Enterprise Server отправляет события pull_request, issue_comment, pull_request_review_comment, pull_request_review и pull_request_target в базовый репозиторий. В вилке репозитория никакие события запросов на вытягивание не происходят.

Запросы на вытягивание из вилки репозитория в частный репозиторий выполняются только при включении. См. раздел Управление параметрами GitHub Actions для репозитория.

pull_request_target

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

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

Чтобы обеспечить безопасность репозитория, ветви с именами, которые соответствуют определенным шаблонам (например, похожими на SHA), могут не запускать рабочие процессы с событием pull_request_target.

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

on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]

pull_request_target Выполнение рабочего процесса на основе заголовка или базовая ветвь запроса на вытягивание

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

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

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Чтобы выполнить задание на основе имени главной ветви запроса на вытягивание (в отличие от имени базовой ветви запроса на вытягивание), используйте контекст github.head_ref в условном режиме. Например, этот рабочий процесс будет выполняться при каждом открытии запроса на вытягивание, но задание run_if будет выполняться только в том случае, если заголовок запроса на вытягивание является ветвью, имя которой начинается с releases/:

on:
  pull_request_target:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

pull_request_target Запуск рабочего процесса на основе файлов, измененных в запросе на вытягивание

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

Например, этот рабочий процесс будет выполняться, когда в запросе на вытягивание изменен файл JavaScript (.js):

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

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

pull_request_target Выполнение рабочего процесса при слиянии запроса на вытягивание

При слиянии запрос на вытягивание автоматически закрывается. Чтобы запустить рабочий процесс при слиянии запроса на вытягивание, используйте тип события pull_request_target closed вместе с условием, проверяющим значение merged события. Например, следующий рабочий процесс будет выполняться при закрытии запроса на вытягивание. Задание if_merged будет выполняться только в том случае, если произошло слияние запроса на вытягивание.

on:
  pull_request_target:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

push

Это событие запускает рабочий процесс при отправке фиксации или тега.

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

on:
  push

Запуск рабочего процесса только при отправке в определенные ветви

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

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

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

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Запуск рабочего процесса только при отправке определенных тегов

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

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

on:
  push:
    tags:
      - v1.**

Запуск рабочего процесса только в случаях, когда отправка влияет на определенные файлы

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

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

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

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

registry_package

jobs:
    job_name:
        if: ${{ github.event.registry_package.package_version.container_metadata.tag.name != '' }}

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

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

on:
  registry_package:
    types: [published]

release

Это событие запускает рабочий процесс при выполнении действия выпуска в репозитории. Сведения об API выпуска см. в разделе Объекты документации по API GraphQL или Выпуски в документации по REST API.

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

on:
  release:
    types: [published]

repository_dispatch

API GitHub Enterprise Server можно использовать для активации события веб-перехватчика repository_dispatch, чтобы активировать рабочий процесс для действия, происходящего за пределами GitHub Enterprise Server. Дополнительные сведения см. в разделе Репозитории.

При запросе на создание события repository_dispatch необходимо указать event_type в качестве описания типа действия. По умолчанию все типы действий repository_dispatch активируют рабочий процесс. Используйте ключевое слово types, чтобы ограничить выполнение рабочего процесса при отправке определенного значения event_type в полезные данные веб-перехватчика repository_dispatch.

on:
  repository_dispatch:
    types: [test_result]

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

{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}

можно получить доступ к полезным данным в рабочем процессе следующим образом:

on:
  repository_dispatch:
    types: [test_result]

jobs:
  run_if_failure:
    if: ${{ !github.event.client_payload.passed }}
    runs-on: ubuntu-latest
    steps:
      - env:
          MESSAGE: ${{ github.event.client_payload.message }}
        run: echo $MESSAGE

schedule

Событие schedule позволяет активировать рабочий процесс в запланированное время.

Можно запланировать выполнение рабочего процесса в определенное время в формате UTC с помощью синтаксиса POSIX cron. Запланированные рабочие процессы запускаются в соответствии с последней фиксацией базовой ветви или ветви по умолчанию. Самый короткий интервал, с которым можно запускать запланированные рабочие процессы — 5 минут.

В этом примере рабочий процесс запускается каждый день в 5:30 и 17:30 (в формате UTC):

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

Один рабочий процесс может запускаться несколькими событиями schedule. Доступ к запланированному событию, при возникновении которого был запущен рабочий процесс, можно получить с помощью контекста github.event.schedule. В этом примере рабочий процесс запускается с ежедневно с понедельника по четверг в 5:30 (в формате UTC), причем по понедельникам и средам шаг Not on Monday or Wednesday пропускается.

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 2,4'

jobs:
  test_schedule:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Monday or Wednesday
        if: github.event.schedule != '30 5 * * 1,3'
        run: echo "This step will be skipped on Monday and Wednesday"
      - name: Every time
        run: echo "This step will always run"

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

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

Эти операторы можно использовать в любом из пяти полей:

Используйте редактор crontab guru, чтобы создавать синтаксис cron и подтверждать время его выполнения. Начать работу можно со списка примеров crontab guru.

Уведомления о запланированных рабочих процессах отправляются пользователю, который внес последние изменения в синтаксис cron файла рабочего процесса. Дополнительные сведения см. в разделе Уведомления о выполнении рабочих процессов.

status

Это событие запускает рабочий процесс при изменении состояния фиксации Git. Фиксации могут быть помечены как error, failure, pending или success. Чтобы предоставить дополнительные сведения об изменении состояния, может потребоваться использовать событие check_run. Сведения об API состояния фиксации см. в разделе Объекты документации по API GraphQL или Фиксации в документации по REST API.

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

on:
  status

Чтобы запустить задание в рабочем процессе на основе нового состояния фиксации, можно использовать контекст github.event.state. Например, следующий рабочий процесс активируется при изменении состояния фиксации, но задание if_error_or_failure выполняется только в том случае, если новое состояние фиксации — error или failure.

on:
  status
jobs:
  if_error_or_failure:
    runs-on: ubuntu-latest
    if: >-
      github.event.state == 'error' ||
      github.event.state == 'failure'
    steps:
      - env:
          DESCRIPTION: ${{ github.event.description }}
        run: |
          echo The status is error or failed: $DESCRIPTION

watch

Это событие запускает рабочий процесс, когда репозиторий рабочего процесса добавляется в избранное. Сведения об API запроса на вытягивание см. в разделе Изменения в документации по API GraphQL или Действие в документации по REST API.

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

on:
  watch:
    types: [starred]

workflow_call

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

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

on: workflow_call

workflow_dispatch

Чтобы включить запуск рабочего процесса вручную, необходимо настроить workflow_dispatch событие . Запустить рабочий процесс вручную можно с помощью API GitHub Enterprise Server, GitHub CLI или интерфейса браузера GitHub Enterprise Server. Дополнительные сведения см. в разделе Запуск рабочего процесса вручную.

on: workflow_dispatch

Предоставление входных данных

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

В этом примере определяются входные данные с именем logLevel, tagsи environment. Значения этих входных данных передаются рабочему процессу при его запуске. Затем этот рабочий процесс выводит значения в журнал с помощью свойств контекста inputs.logLevel, inputs.tags и inputs.environment.

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}
          ENVIRONMENT: ${{ inputs.environment }}

При запуске этого рабочего процесса из браузера необходимо сначала ввести значения необходимых входных данных вручную.

Входные данные также можно передавать при запуске рабочего процесса из скрипта или с помощью GitHub CLI. Пример:

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

Дополнительные сведения см. в разделе GitHub CLI в разделе "Запуск рабочего процесса вручную".

workflow_run

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

В этом примере запуск рабочего процесса выполняется после завершения отдельного рабочего процесса Run Tests.

on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed

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

on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed

Запуск рабочего процесса на основе результатов другого рабочего процесса

Запуск рабочего процесса выполняется независимо от результатов предыдущего рабочего процесса. Чтобы запустить задание или шаг на основе результата запуска рабочего процесса, можно использовать условие со свойством github.event.workflow_run.conclusion. Например, этот рабочий процесс будет выполняться всякий раз, когда завершается рабочий процесс Build, однако задание on-success будет выполняться только в случае, если рабочий процесс Build выполнен успешно, а задание on-failure будет выполняться только в случае, если рабочий процесс Build завершился ошибкой:

on:
  workflow_run:
    workflows: [Build]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'

Ограничение запуска рабочего процесса на основе ветвей

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

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

Использование данных из рабочего процесса, активирующего триггер

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

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

name: Upload data

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest

    steps:
      - name: Save PR number
        env:
          PR_NUMBER: ${{ github.event.number }}
        run: |
          mkdir -p ./pr
          echo $PR_NUMBER > ./pr/pr_number
      - uses: actions/upload-artifact@v3
        with:
          name: pr_number
          path: pr/

После завершения указанного выше рабочего процесса запускается следующий рабочий процесс. Следующий рабочий процесс использует контекст github.event.workflow_run и REST API GitHub Enterprise Server для скачивания артефакта, отправленного указанным выше рабочим процессом. Затем он распаковывает скачанный артефакт и создает комментарии к запросу на вытягивание, номер которого был отправлен в качестве артефакта.

name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v6
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            let fs = require('fs');
            fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip pr_number.zip

      - name: 'Comment on PR'
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            let fs = require('fs');
            let issue_number = Number(fs.readFileSync('./pr_number'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });