To automate your pipelines, you will want to set them up to run whenever some event occurs. Those events might be:
A commit to a source code repository
A source code repository branch or pull request
Some other external event
At some regular time interval
Steps automatically execute when they are triggered by some change event in a resource. Your pipeline should be constructed so that when each step makes some change to a resource, that change triggers execution of the next step. In this way, all the steps of your pipeline will execute in sequence.
To trigger a step for execution:
Specify the triggering event(s) in a resource.
Specify that resource as an
inputresource
of a step.
The specified change in that resource will then automatically trigger the step to run. When that step is the first step in the pipeline, it will initiate the entire run of that pipeline.
Triggering On a Git Repository Change
A Git source code repository is represented by a GitRepo resource. The events that cause a GitRepo to trigger can be specified in the buildOn
group of tags.
The most commonly used event for triggering a run of a pipeline is any commit
to the Git repository. For this reason, the value of this tag defaults to true. So if that is the only event you want to trigger on, then you do not need to specify buildOn
tags at all in the GitRepo resource.
Your GitRepo can be set to trigger on any of these buildOn
events:
Tag | Default | Event |
---|---|---|
| false | An existing branch is deleted |
| true | A new commit to the Git repo Note that when this is set as |
| false | A new pull request made to the Git repo |
| false | A pull request to the Git repo is closed |
| false | A new release request made to the Git repo |
| false | Creation of a new tag ref in the Git repo |
Skipping a Git Repository Commit
If a specific commit should not trigger any runs for a GitRepo resource, include the text [skipRun]
anywhere in the commit message and no runs will be triggered by that commit.
For example, to commit a change from the GitHub command line:
$ git commit -m "[skipRun] Fixed spelling errors in comments"
# Commits the tracked changes but does not trigger Pipelines.
The GitRepo resource will still be updated so that it will be current to the latest version of the repository for any Pipelines step that references that GitRepo resource.
The [skipRun]
directive suppresses triggering only for a commit
event. The GitRepo resource will still trigger on other buildOn
events (such as a pull request) if those events are set to true
.
Cancelling Previous Runs On a Git Repository Change
By default, when a GitRepo buildOn
event (e.g., a commit) triggers a run for a pipeline that is already queued or is in-progress from a prior trigger, Pipelines will queue a new run of that pipeline. The new run executes after the prior run completes.
A GitRepo resource can be optionally configured to automatically cancel any queued or in-progress run that was triggered by the same GitRepo resource.
Your GitRepo can be set to cancel on any of thesecancelPendingRunsOn
events:
Tag | Default | Event |
---|---|---|
| false | commit: previous runs for the same branch are cancelled tag: previous runs for the same tag name are cancelled release: previous runs for the same release name are cancelled |
| false | previous runs for the same pull request number are cancelled |
Runs will only be cancelled for change events of the same type. For example, a commit will only cancel runs triggered by previous commits to the same branch.
Triggering On a Webhook
You may trigger execution on receipt of a webhook from an external source.
Create an IncomingWebhook resource that is configured to use an Incoming Webhook Integration, then include it in the inputresources
block of the step to trigger. Any payload from the webhook will be available in the resource's environment variable $res_<resource_name>_payload,
which can be written to a file. You can then use the read_json utility function to retrieve individual elements from the JSON payload into environment variables.
Triggering On a Time Schedule
A common practice for many organizations is to perform regular nightly builds during off-peak usage hours. For example, you may wish to execute the run of pipeline every night at 3:00am.
To trigger at a specific time or at regular time intervals, use the CronTrigger resource to specify the time or interval. In this resource you can specify a cron expression string. When you specify the CronTrigger
resource as an inputresource
to the first step in a pipeline, the pipeline will automatically commence execution at that time or interval.