---
metadata:
  - name: generator
    content: Diplodoc Platform v5.57.3
alternate:
  - https://sourcecraft.dev/portal/docs/en/sourcecraft/ci-cd-ref/on.md
  - https://sourcecraft.dev/portal/docs/ru/sourcecraft/ci-cd-ref/on.md
  - href: https://sourcecraft.dev/portal/docs/ru/sourcecraft/ci-cd-ref/on.md
    type: text/markdown
    title: Markdown version
  - href: https://sourcecraft.dev/portal/docs/ru/llms.txt
    type: text/markdown
    title: llms.txt
---
> **Documentation Index:** Fetch the complete configuration index at https://sourcecraft.dev/portal/docs/ru/llms.txt

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

<!-- source: ru/_includes/sourcecraft/ci-cd/on-description.md -->
В блоке `on` настраиваются _события-триггеры_, которые будут запускать [рабочие процессы](https://sourcecraft.dev/portal/docs/ru/sourcecraft/concepts/ci-cd.md#workflows) CI/CD в репозитории. Такими событиями могут быть отправка изменений в ветку удаленного репозитория (`push`), создание предложения изменений (`pull_request`) или запуск по расписанию (`schedule`).

{% note warning %}

Чтобы событие-триггер сработало, файл `.sourcecraft/ci.yaml` должен находиться в основной ветке репозитория, например `main` или `master`. Установить основную ветку можно в [настройках репозитория](https://sourcecraft.dev/portal/docs/ru/sourcecraft/operations/repo-edit.md).

{% endnote %}

Для разных событий вы можете настроить разные рабочие процессы. Также срабатывание триггеров можно настроить для конкретных веток или путей в репозитории.
<!-- endsource: ru/_includes/sourcecraft/ci-cd/on-description.md -->

Поддерживаются следующие типы событий-триггеров:
* [push](#push) — отправка изменений в ветку удаленного репозитория.
* [pull_request](#pull-request) — создание [предложения изменений](https://sourcecraft.dev/portal/docs/ru/sourcecraft/concepts/index.md#pr).
* [schedule](#schedule) — запуск по расписанию.

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

## push {#push}

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

{% note warning %}

Событие-триггер `push` не создается, если в рамках одной отправки изменений обновляются более 5000 веток или более 100 тегов.

{% endnote %}

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

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

##### Пример простого события-триггера push с одним рабочим процессом {#simple-push-one-process}

```yaml
on:
  push: my-workflow
```

##### Пример простого события-триггера push с одним рабочим процессом списком {#simple-push-one-process-list}

```yaml
on:
  push:
    - my-workflow
```

##### Пример простого события-триггера push с несколькими рабочими процессами {#simple-push-many-processes}

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

##### Пример простого события-триггера push с несколькими рабочими процессами списком {#simple-push-many-processes-list}

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

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

Поддерживаются следующие параметры:
* [workflows](#complex-push-workflows)
* [filter](#complex-push-filter) (опционально)
* [skip_on_pull_request](#complex-push-skip) (опционально)

### workflows {#complex-push-workflows}

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

##### Пример сложного события-триггера push с одним рабочим процессом {#complex-push-one-process}

```yaml
...
workflows: my-workflow
...
```

##### Пример сложного события-триггера push с несколькими рабочими процессами {#complex-push-many-processes}

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

### filter {#complex-push-filter}

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

Поддерживаются следующие параметры:
* [paths](#complex-push-paths) — фильтр или список фильтров по путям изменившихся файлов.
* [branches](#complex-push-branches) — фильтр или список фильтров по именам веток.
* [tags](#complex-push-tags) — фильтр или список фильтров по именам тегов.

<!-- source: ru/_includes/sourcecraft/ci-cd/filter-tag-with-others.md -->
{% note warning %}

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

Чтобы настроить запуск рабочего процесса как по именам веток и путям, так и по именам тегов, опишите в конфигурации два различных события: с фильтрами `branches` и `paths`, и с фильтром `tags`. Примеры в разделе [Пример сложного события-триггера push с фильтрами по тегам, путям и веткам](https://sourcecraft.dev/portal/docs/ru/sourcecraft/ci-cd-ref/on.md#complex-push-tags-branches-paths).

{% endnote %}
<!-- endsource: ru/_includes/sourcecraft/ci-cd/filter-tag-with-others.md -->

#### paths {#complex-push-paths}

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

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

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

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

{% note tip %}

Используйте фильтр с отрицанием только совместно с другими фильтрами по путям. Сам по себе фильтр с отрицанием только запрещает запуск события-триггера. Подробнее в [примере](#complex-push-many-paths-with-not).

{% endnote %}

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

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

Подробнее о синтаксисе и правилах применения фильтров в разделе [Фильтры и паттерны в SourceCraft](https://sourcecraft.dev/portal/docs/ru/sourcecraft/concepts/filters-by-paths.md).

##### Пример сложного события-триггера push с одним фильтром по пути {#complex-push-one-path}

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

##### Пример сложного события-триггера push с несколькими фильтрами по путям {#complex-push-many-paths}

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

##### Пример сложного события-триггера push с несколькими фильтрами по путям, в том числе с отрицанием {#complex-push-many-paths-with-not}

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

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

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

#### branches {#complex-push-branches}

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

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

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

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

{% note tip %}

Используйте фильтр с отрицанием только совместно с другими фильтрами по веткам. Сам по себе фильтр с отрицанием только запрещает запуск события-триггера. Подробнее в [примере](#complex-push-many-branches-with-not).

{% endnote %}

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

Подробнее о синтаксисе и правилах применения фильтров в разделе [Фильтры и паттерны в SourceCraft](https://sourcecraft.dev/portal/docs/ru/sourcecraft/concepts/filters-by-paths.md).

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

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

##### Пример сложного события-триггера push с несколькими фильтрами по именам веток {#complex-push-many-branches}

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

##### Пример сложного события-триггера push с несколькими фильтрами по именам веток, в том числе с отрицанием {#complex-push-many-branches-with-not}

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

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

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

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

#### tags {#complex-push-tags}

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

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

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

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

{% note tip %}

Используйте фильтр с отрицанием только совместно с другими фильтрами по тегам. Сам по себе фильтр с отрицанием только запрещает запуск события-триггера. Подробнее в [примере](#complex-push-many-tags-with-not).

{% endnote %}

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

<!-- source: ru/_includes/sourcecraft/ci-cd/filter-tag-with-others.md -->
{% note warning %}

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

Чтобы настроить запуск рабочего процесса как по именам веток и путям, так и по именам тегов, опишите в конфигурации два различных события: с фильтрами `branches` и `paths`, и с фильтром `tags`. Примеры в разделе [Пример сложного события-триггера push с фильтрами по тегам, путям и веткам](https://sourcecraft.dev/portal/docs/ru/sourcecraft/ci-cd-ref/on.md#complex-push-tags-branches-paths).

{% endnote %}
<!-- endsource: ru/_includes/sourcecraft/ci-cd/filter-tag-with-others.md -->

Подробнее о синтаксисе и правилах применения фильтров в разделе [Фильтры и паттерны в SourceCraft](https://sourcecraft.dev/portal/docs/ru/sourcecraft/concepts/filters-by-paths.md).

##### Пример сложного события-триггера push с одним фильтром по имени тега {#complex-push-one-tag}

```yaml
...
filter:
...
  tags: "version-*"
...
```

##### Пример сложного события-триггера push с несколькими фильтрами по имени тегов, в том числе с отрицанием {#complex-push-many-tags-with-not}

```yaml
...
filter:
...
  tags: ["version-*", "!version-alpha-*"]
...
```

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

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

```yaml
...
filter:
...
  tags: ["**", "!version-alpha-*"]
...
```

##### Пример сложного события-триггера push с фильтрами по тегам, путям и веткам {#complex-push-tags-branches-paths}

Чтобы рабочий процесс `ci-workflow` был запущен как по изменению содержимого директории `ci/**` в ветке `main`, так и по пушу тега `ci-version-*`, создайте два отдельных события-триггера:

```yaml
on:
  push:
    - workflows: ci-workflow
      filter:
        branches: "main"
        paths: "ci/**"
    - workflows: ci-workflow
      filter:
        tags: "ci-version-*"
```

### skip_on_pull_request {#complex-push-skip}

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

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

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

{% note info %}

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

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

{% endnote %}

##### Пример одного сложного события-триггера push {#complex-push-examples}

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

##### Пример комбинации простого и сложного событий-триггеров push {#simple-complex-push-examples}

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

## pull_request {#pull-request}

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

Аналогично блоку [push](#push), блок `pull_request` поддерживает [простые](#simple-push) и [сложные](#complex-push) события-триггеры.

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

##### Пример события-триггера pull_request без фильтров {#pull-request-without-filters}

```yaml
on:
  pull_request: my-workflow
```

##### Пример события-триггера pull_request со всеми фильтрами {#pull-request-with-all-filters}

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

## schedule {#schedule}

Блок `schedule` запускает в основной ветке репозитория, например `main` или `master`, рабочие процессы по расписанию. Поддерживаются следующие параметры:
* `workflows` — аналогично полю `push:workflows`.
* `interval` — интервал запуска в часах или минутах, например `1h` или `7m`. Минимальное значение — `1m`. Нельзя использовать совместно с параметром `cron`.
* `cron` — [cron-выражение](https://ru.wikipedia.org/wiki/Cron), например `"25 * * * *"` — каждый час на 25-й минуте. Нельзя использовать совместно с параметром `interval`.
* `description` — (опционально) произвольное описание.

{% note warning %}

Запуск рабочего процесса по расписанию осуществляется от имени пользователя, который последним отредактировал блок `schedule` в файле `.sourcecraft/ci.yaml` в основной ветке. Учитываются изменения всех полей расписания, кроме `description`.

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

{% endnote %}

При запуске рабочих процессов по расписанию поддерживается использование входных параметров [inputs](https://sourcecraft.dev/portal/docs/ru/sourcecraft/ci-cd-ref/workflows.md#inputs). Подробнее в разделе [Пример событий-триггеров schedule с использованием блока inputs](#inputs-schedule).

##### Пример событий-триггеров schedule {#schedule-example}

```yaml
on:
  schedule:
    - workflows: first-workflow
      interval: 30m
      description: interval schedule

    - workflows: 
        - first-workflow
        - second-workflow
      cron: "25 * * * *"
      description: cron schedule
```

Согласно данной конфигурации, в основной ветке репозитория будут автоматически запускаться следующие рабочие процессы:
* `first-workflow` каждые 30 минут.
* `first-workflow` и `second-workflow` каждый час на 25-й минуте.

##### Пример событий-триггеров schedule с использованием блока inputs {#inputs-schedule}

```yaml
on:
  # Запуск рабочих процессов по расписанию
  schedule:
    - interval: 1h
      workflows:
        # Запуск рабочего процесса с одними входными параметрами
        echo-inputs-workflow:
          inputs:
            first: "Hello"
            second: "Bye"
    - interval: 30m
      workflows:
        # Запуск того же рабочего процесса, но с другими входными параметрами
        echo-inputs-workflow:
          inputs:
            - name : first
              value : "Привет"
            - name : second
              value : "Пока"
        # Запуск рабочего процесса без входных параметров
        workflow-without-inputs: {}

workflows:
  echo-inputs-workflow:
    inputs:
      # Объявление входных параметров
      first:
        type: string
        description: First input value
      second:
        type: string
        description: Second input value
    tasks:
      - sample-task
  workflow-without-inputs:
    tasks:
      - another-task

tasks:
  - name: sample-task
    # Объявление переменных окружения с использованием входных параметров
    env:
      FIRST_MESSAGE: ${{ inputs.first }}
      SECOND_MESSAGE: ${{ inputs.second }}
    cubes:
      - name: sample-cube
        script:
          - echo $FIRST_MESSAGE
          - echo $SECOND_MESSAGE
  - name: another-task
    cubes:
      - name: sample-cube-2
        script:
          - echo "Hello world!"
```

#### Полезные ссылки {#see-also}

* [Рабочие процессы (workflows)](https://sourcecraft.dev/portal/docs/ru/sourcecraft/ci-cd-ref/workflows.md)
* [Задания (tasks)](https://sourcecraft.dev/portal/docs/ru/sourcecraft/ci-cd-ref/tasks.md)
* [Непрерывная интеграция и непрерывное развертывание в SourceCraft](https://sourcecraft.dev/portal/docs/ru/sourcecraft/concepts/ci-cd.md)
* [Настроить CI/CD в репозитории SourceCraft](https://sourcecraft.dev/portal/docs/ru/sourcecraft/operations/ci-cd.md)