События-триггеры (on)

В блоке on настраиваются события-триггеры, которые будут запускать рабочие процессы CI/CD в репозитории.

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

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

Поддерживаются следующие типы событий-триггеров:

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

push

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

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

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

Пример простого события-триггера push с одним рабочим процессом

on:
  push: my-workflow

Пример простого события-триггера push с одним рабочим процессом списком

on:
  push:
    - my-workflow

Пример простого события-триггера push с несколькими рабочими процессами

on:
  push: [my-workflow-1, my-workflow-2]

Пример простого события-триггера push с несколькими рабочими процессами списком

on:
  push:
    - [my-workflow-1, my-workflow-2]

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

Поддерживаются следующие параметры:

workflows
filter (опционально)
skip_on_pull_request (опционально)

workflows

В поле workflows указывается имя (или список имен) рабочих процессов, которые будут запущены. Если никаких рабочих процессов не указано, сложное событие-триггер задается для всех рабочих процессов.

Пример сложного события-триггера push с одним рабочим процессом

...
workflows: my-workflow
...

Пример сложного события-триггера push с несколькими рабочими процессами

...
workflows: [my-workflow-1, my-workflow-2]
...

filter

В поле filter указываются дополнительные настройки, которые будут учитываться при срабатывании сложного события-триггера.

Поддерживаются следующие параметры:

paths — фильтр или список фильтров по путям изменившихся файлов.
branches — фильтр или список фильтров по именам веток.
tags — фильтр или список фильтров по именам тегов.

Важно

В блоке filter нельзя использовать фильтр tags одновременно с branches, paths и их комбинацией. Совмещение параметра tags с branches и paths является синтаксической ошибкой.

Чтобы настроить запуск рабочего процесса как по именам веток и путям, так и по именам тегов, опишите в конфигурации два различных события: с фильтрами branches и paths, и с фильтром tags. См. пример.

paths

В поле paths указывается фильтр или список фильтров по путям изменившихся файлов.

Если поле paths не указано, то фильтр по путям не применяется.

Если поле paths указано как пустой список, то соответствующее сложное событие-триггер никогда не сработает.

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

Совет

Используйте фильтр с отрицанием только совместно с другими фильтрами по путям. Сам по себе фильтр с отрицанием только запрещает запуск события-триггера. Подробнее см. в примере.

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

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

Пример сложного события-триггера push с одним фильтром по пути

...
filter:
...
  paths: "pkg/**"
...

Пример сложного события-триггера push с несколькими фильтрами по путям

...
filter:
...
  paths: ["pkg/**", "internal/**"]
...

Пример сложного события-триггера push с несколькими фильтрами по путям, в том числе с отрицанием

...
filter:
...
  paths: ["internal/**", "!internal/generated/**", "internal/generated/models/auth/**"]
...

Попадать под действие фильтра будут, например, файлы internal/auth/auth.go и internal/generated/models/auth/auth.go. Файл internal/generated/models/data/data.go не попадет под действие фильтра.

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

...
filter:
...
  paths: ["**", "!internal/generated/**"]
...

branches

В поле branches указывается фильтр или список фильтров по именам веток.

Если поле branches не указано, то фильтр по именам веток не применяется.

Если поле branches указано как пустой список, то соответствующее сложное событие-триггер никогда не сработает.

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

Совет

Используйте фильтр с отрицанием только совместно с другими фильтрами по веткам. Сам по себе фильтр с отрицанием только запрещает запуск события-триггера. Подробнее см. в примере.

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

Пример сложного события-триггера push с одним фильтром по имени ветки

...
filter:
...
  branches: "feature/**"
...

Пример сложного события-триггера push с несколькими фильтрами по именам веток

...
filter:
...
  branches: ["feature/**", "bugfix/**"]
...

Пример сложного события-триггера push с несколькими фильтрами по именам веток, в том числе с отрицанием

...
filter:
...
  branches: ["feature/**", "!feature/internal/**", "feature/internal/security/**"]
...

Попадать под действие фильтра будут, например, ветки feature/OO-7 и feature/internal/security/OO-777. Ветка feature/internal/OO-77 не попадет под действие фильтра.

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

...
filter:
...
  branches: ["**", "!feature/internal/**"]
...

skip_on_pull_request

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

Например, при следующей конфигурации будут игнорироваться события-триггеры push для веток feature/**, если есть открытое предложение изменений из этих веток в другие.

on:
  push:
    - workflows: o_yaml
      filter:
        branches: "feature/**"
      skip_on_pull_request: true

Примечание

Пока нет открытых предложений изменений из указанных веток, поведение будет полностью аналогично событию-триггеру on:push без указанного параметра skip_on_pull_request: true.

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

Пример одного сложного события-триггера push

on:
  push:
    workflows: ci-workflow
    filter:
      branches: "feature/**"
      paths: "ci/**"

Пример комбинации простого и сложного событий-триггеров push

on:
  push:
    - common-workflow-1
    - [common-workflow-2, common-workflow-3]
    - workflows: ci-workflow
      filter:
        branches: "feature/**"
        paths: "ci/**"

pull_request

Блок pull_request запускает рабочие процессы после создания предложения изменений.

Аналогично блоку push, блок pull_request поддерживает простые и сложные события-триггеры.

Для сложных событий-триггеров поддерживаются следующие параметры:

workflows — аналогично полю push:workflows;
filter:
- paths – аналогично полю push:filter:paths
- source_branches – фильтрация по веткам, из которых приходят изменения;
- target_branches – фильтрация по веткам, в которые планируется влить изменения.

Пример события-триггера pull_request без фильтров

on:
  pull_request: my-workflow

Пример события-триггера pull_request со всеми фильтрами

on:
  pull_request:
    - workflows: [ci-workflow, ide-workflow]
      filter:
        source_branches: "feature/**"
        target_branches: ["master", "feature/**"]
        paths: "ci/**"

См. также

Была ли статья полезна?

Обзор

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