Trigger, a key term used, to represent a step to automate deployment or initiate a pipeline build. As seen in the table below taken from CD.Foundation’s mapping of common terminologies, trigger is used by almost all CI/CD tools available.
Likewise in harness are used in deployments to automate the CI/CD pipeline based on various git events namely PUSH, CREATE & ALL, which thereby can be used to trigger a pipeline automatically based on these events.
Why do we need it?
Triggers enable event driven CI/CD and support the practice of every commit building and/or deploying to a target environment.
How Triggers are based on various git events?
Pipelines could be triggered in response to Git events automatically. For example, when a pull request or push event occurs on a Git repo, a CI or CD Pipeline can execute.
The triggers work on a certain predefined conditions, which help to form the overall set of criteria to trigger a Pipeline based on changes in a given source. In harness we have categorised the conditions to be based on 3 git events:
Pull Request
Issue Comment
Push
Which are further attributed by
For example:
Execute Pipeline if the source/target branch name matches a pattern.
Execute Pipeline if the event is sent for file changes from specific directories in the Git repo. This is very useful when working with a monorepo (mono repository). It ensures that only specific Pipelines are triggered in response to a change.
Making it work with GitHub web-hooks:
For configuring the GitHub web-hooks harness uses events API to choose which events will send the payloads.
Here’s an example of payloads conditions described in Harness for triggers:
The following resources could be used to get more information on how trigger Pipelines in response to Git events that match specific payload conditions you set up in the Harness Trigger, also to customize the trigger for Github payload conditions:
.svg)
.png)
.svg){kind=small}
