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

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

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

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

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

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

push

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

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

Простое событие-триггер push

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

Примеры простых событий-триггеров push

  • Один рабочий процесс:

    on:
          push: my-workflow

  • Один рабочий процесс списком:

    on:
          push:
            - my-workflow

  • Несколько рабочих процессов:

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

  • Несколько рабочих процессов списком:

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

Сложное событие-триггер push

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

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

workflows

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

Примеры:

  • Один рабочий процесс:

    ...
        workflows: my-workflow
        ...

  • Несколько рабочих процессов:

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

filter

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

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

paths

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

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

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

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

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

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

Примеры:

  • Один фильтр по пути:

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

  • Несколько фильтров по путям:

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

  • Несколько фильтров по путям, в том числе с отрицанием:

    ...
        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 не попадет под действие фильтра.

branches

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

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

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

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

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

Примеры:

  • Один фильтр по имени ветки:

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

  • Несколько фильтров по именам веток:

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

  • Несколько фильтров по именам веток, в том числе с отрицанием:

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

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

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/**"

  • Комбинация простого и сложного событий-триггеров:

    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

  • Со всеми фильтрами:

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

См. также

Предыдущая
Обзор
Следующая
Рабочие процессы (workflows)