Pipelines in Go can get triggered in several ways. Given below is a quick guide describing the behavior of these different trigger types.
1. Automatic Trigger
Go server polls all materials to get latest changes, approximately, once per minute. A pipeline gets triggered automatically whenever there is a new checkin detected for its material. During automatic trigger, material revisions are resolved based on upstream dependencies of the pipeline.
Special Cases:
(i) If the polling of the material is disabled, then the pipeline will not get automatically triggered.
(ii) If the first stage of a pipeline is manual then the pipeline will not get triggered, irrespective of whether the polling is disabled or enabled.
(iii) If some files in the material have been blacklisted, changes to these files also will not trigger the pipeline.
2. Manual Trigger.
A pipeline can be manually triggered by using the "Play" or "Trigger" button available on the dashboard. It can also be triggered using the schedule API. When a pipeline is manually triggered, the Go server mandatorily polls for the latest changes of all the materials and schedules the pipeline.
Few things to keep in mind while triggering a pipeline:
(i) Manual trigger does not resolve the changes based on fanin or upstream dependencies.
(ii) Any pipeline can be manually triggered irrespective of its configuration.
A pipeline can also be manually triggered with any selected revisions. This can be done either by using the "Trigger with Options" button on the dashboard, or via the schedule API. It is to be noted that the revisions available for selection will only be those that the Go server already knows about.
3. Timer Trigger
A pipeline can be configured to run at a specific time e.g.: 8 a.m every monday morning. The timer can be configured using a cron-like format. Go server uses the last known revisions of the materials to trigger the pipeline. It does not poll the material to get the latest changes.
Few things to keep in mind while configuring your pipeline to be timer trigger:
(i) If polling is turned off for the material, the Go server will not know about any new revisions checked into the material and hence the timer pipeline will not run with them.
(ii) The pipeline will get triggered on the scheduled time, even if a previous pipeline instance has already run with the same set of material revisions.
(iii) If it is desirable that the pipeline should trigger only on the scheduled time and not on every check-in, the first stage should be made manual.
Comments
4 comments
Note: The 'timer can be configured' link takes you to thoughtworks-studios.com which has a certificate error because the cert doesn't contain the Subject Alternative Name for 'thoughworks-studios.com'.
Thanks Shaun for pointing it out, I have updated the links.
It seems to me that a fairly common use case would be to have a pipeline that runs on a timer but not on each commit (e.g., to Git). One would believe that this is what you would get if you configure the pipeline to run on a timer and add git repos as materials but with "Poll for changes" unchecked.
But this is not the case...
As described on this page you get different behaviors on manual triggering compared to a timer triggering of a pipeline in that material is updated in the first case but not the second. Very confusing.
This should be highlighted in the official documentation. Now we we need to workaround this difference in behavior by adding a task "git clone" in each job instead of configuring it once on the pipeline and we have many jobs in our pipelines...
Or is it so that we can do what is described in the last sentence on this page?
"(iii) If it is desirable that the pipeline should trigger only on the scheduled time and not on every check-in, the first stage should be made manual."
Confusing indeed.
Hi Svante,
This forum is available only for reference. When we GoCD was open sourced, we moved the community to google groups. Please redirect your queries to the go-cd google group
Thanks,
Mansi
Article is closed for comments.