Trigger events (on)

Under on, you can configure the repository events that will start the CI/CD workflows.

Such events may include pushing changes to a remote repository branch or creating a pull request.

You can configure different workflows for different events. You can also configure triggers for specific branches or paths in the repository.

The following types of trigger events are supported:

If the trigger events are not specified, the push trigger event will be set for all workflows by default without any additional settings.

push

The push section runs workflows after pushing changes to a remote repository branch.

If the push section is present but its parameters are not specified, the push trigger event will be set for all workflows by default without any additional settings.

Simple push trigger event

A simple trigger event specifies only the name or list of names of workflows it will set off.

Examples of simple push trigger events

One workflow:
```
on:
  push: my-workflow
```
One workflow as a list:
```
on:
  push:
    - my-workflow
```

Multiple workflows:

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

Multiple workflows as a list:

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

Complex push trigger event

In addition to the name or list of names of workflows it will set off, a complex trigger event specifies additional settings to apply if triggered.

The following parameters are supported:

workflows

The workflows field specifies the name (list of names) of workflow(s) the event will set off. If no workflows are specified, the complex trigger event is set for all workflows.

Examples:

One workflow:
```
...
workflows: my-workflow
...
```

Multiple workflows:

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

filter

The filter field specifies the additional settings to apply when the complex trigger event is triggered.

The following parameters are supported:

paths

The paths field specifies a filter or list of filters based on the modified files' paths.

If the paths field is not set, filtering by path is not used.

If the paths field is set as an empty list, the relevant complex trigger event will never be triggered.

You can specify filtering by path with a negation (!), in which case the relevant complex trigger event will be triggered if the paths of modified files are not subject to the filter.

Keep in mind that filters by path are applied one by one. In other words, after a filter with a negation, you can specify a filter without one that may cover, partially or fully, the effect of the filter with a negation.

If it is impossible for any reason to calculate paths of modified files, it will be considered that the changes are subject to the filter.

Examples:

One filter by path:
```
...
filter:
...
  paths: "pkg/**"
...
```

Multiple filters by path:

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

Multiple filters by path, including with a negation:
```
...
filter:
...
  paths: ["internal/**", "!internal/generated/**", "internal/generated/models/auth/**"]
...
```
The filter will apply to such files as internal/auth/auth.go and internal/generated/models/auth/auth.go. The filter will not apply to the internal/generated/models/data/data.go file.

branches

The branches field specifies a filter or list of filters based on branch names.

If the branches field is not set, filtering by branch name is not used.

If the branches field is set as an empty list, the relevant complex trigger event will never be triggered.

You can specify filtering by branch name with a negation (!), in which case the relevant complex trigger event will be triggered if the branch name is not subject to the filter.

Keep in mind that filters by branch name are applied one by one. In other words, after a filter with a negation, you can specify a filter without one that may cover, fully or partially, the effect of the filter with a negation.

Examples:

One filter by branch name:

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

Multiple filters by branch name:

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

Multiple filters by branch name, including with a negation:
```
...
filter:
...
  branches: ["feature/**", "!feature/internal/**", "feature/internal/security/**"]
...
```
The filter will apply to such branches as feature/OO-7 and feature/internal/security/OO-777. The filter will not apply to the feature/internal/OO-77 branch.

Examples of complex push trigger events

One complex trigger event:

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

Combination of a simple trigger event and complex trigger events:

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

pull_request

The pull_request section runs workflows after creating a pull request.

Same as the push section, pull_request supports simple and complex trigger events.

For complex trigger events, the following parameters are supported:

workflows: Same as the push:workflows field.
filter:
- paths: Same as the push:filter:paths field.
- source_branches: Filtering based on branches the changes come from.
- target_branches: Filtering based on branches the changes will be added to.

Examples of pull_request trigger events

Without filters:
```
on:
  pull_request: my-workflow
```

With all filters:

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

Trigger events (on)

push

Simple push trigger event

Examples of simple push trigger events

Complex push trigger event

workflows

filter

paths

branches

Examples of complex push trigger events

pull_request

Examples of pull_request trigger events

See also

Was the article helpful?