Here’s a quick quiz:
Say we have a timer-based pipeline set to run once a day. Say this pipeline has a GitHub repository as one of its materials. By default, how frequently will Go poll this GitHub repository for changes?
If you answered once every minute, you’d be right. This is because the scheduling sub-system in Go is separate from the material sub-system. The timer only affects scheduling, not material update.
So what do we do if we don’t want GitHub to be hit every minute? Well, we could turn off autoUpdate for this material. However, this has the unfortunate side-effect that the pipeline will run with stale material when the timer triggers. So it will run once every day alright but with the same old material it last saw when we turned autoUpdate off.
We can work around this problem by noting that although a timer trigger does not initiate a material update, a manual (or API) trigger does. We change our pipeline to be a purely manual pipeline by removing the timer trigger. This pipeline can still be triggered by API. We create another timer-based pipeline whose sole purpose is to trigger the original pipeline via API. API trigger initiates a material update so our pipeline will run with latest updates. Problem solved!
Note: The new triggering pipeline cannot be created without a material, so we assign the same GitHub repository as material to it (since autoUpdate is turned off for this material, this assignment has no side effect).