We all know how to enable our Builds as CI Pipelines, and our Releases as CD Pipelines. No big deal there.
But sometimes it is necessary or just helpful to run some pipeline at defined intervals, or in a scheduled manner.
Let's see how, with the help of Azure Pipelines Schedule trigger.
Intro
This is the second post in the series about Azure Pipelines Triggers.
In the previous post, we have seen how to kick off our release pipelines every time a new container image is pushed to a registry.
Today instead we are going in a quite different direction, we are going to talk about Scheduling the executions of our pipelines using the Schedule trigger.
Once again I'll focus first on the Classic Release Pipelines, using the UI, and then on the YAML Pipelines. Stay with me until the end because the behaviour of the two is quite different.
Finally I will also show you how to check when your scheduled pipelines will run next.
Video
If you are a visual learner or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation, which to be fair is much more complete than this post.
If you rather prefer reading, well... let's just continue :)
Classic Build Pipelines
Let's start with the Classic Build. Go to your Pipeline page, then Edit, Triggers, Schedule.
Here you can select the days and time when you want to run the build.
You can also make the scheduled pipeline run only if either the source code or the pipeline has changed between the previous execution and the scheduled one.
If your repository is Azure Repos Git, GitHub, or Other Git, then you can also specify branches to include in and exclude from the build.
And you can use wildcards, just type the branch specification (for example, features/modules/*) and then press Enter.
And this is basically it for the Classic build. Let's talk about the Classic Release pipelines now.
Classic Release Pipelines
Let's go to Releases, Edit and this time use the Schedule button
This will open a very familiar panel where we can set all the settings we need for the schedule:
And remember that the time is expressed in 24 hours.
As you can see, scheduling Builds and Releases using the Classic editor is super easy and intuitive.
Alright, let's see now how to achieve the same with the Multistage YAML Pipelines.
YAML Pipelines
There are 2 ways to schedule a YAML Pipeline: using the settings UI and using the YAML syntax.
But we need to be careful, because scheduled triggers defined using the pipeline settings UI take precedence over YAML ones.
If your YAML pipeline has both YAML scheduled triggers and UI-defined scheduled triggers, only the UI defined scheduled triggers are run. To run the YAML defined scheduled triggers in your YAML pipeline, you must remove the scheduled triggers defined in the pipeline setting UI. Once all UI scheduled triggers are removed, a push must be made in order for the YAML scheduled triggers to start running.
Let's take a look at the triggers from the setting UI first.
Once again, just go to your Pipeline edit page, then click on the ellipses and select triggers
Easy right? And the Ui is identical to the Classic Pipelines one... with of course the "inconvenient" of the override.
But let's talk about YAML.
First of all, if you want to run your pipeline by ONLY using scheduled triggers, you must disable PR and continuous integration triggers.
The easiest way to do so is using:
trigger: none
Next we need to add the schedules. For example:
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- master
- releases/*
exclude:
- releases/old/*
- cron: "0 */6 * * *"
displayName: Every 6 hours build
branches:
include:
- releases/*
always: true
In this case I have 2 schedules.
As you can see, the trigger uses the CRON syntax.
If you are not familiar with the CRON syntax, here you have something for your reference.
It's basically a numerical way to express time and dates for scheduling purposes.
It starts with minutes, then hours, days, months and days of weeks.
And for each field, apart from the values you can see here. you can also use wildcards like star to match every possible value or intervals.
Going back to the schedules, there are some things you need to keep in mind.
First, you must use the "include" keyword. In the Classic Pipelines you can omit that, and the engine will take the whole content of the repo. With the YAML Pipelines, it won't work. The "exclude" part is instead optional.
Second, by default the Classic Pipelines will execute anyway, no matter what, unless you optionally enable the "Only schedule builds if the source or pipeline has changed" checkbox. With YAML, instead, you need to manually tell Azure Pipelines that you want to always execute the Pipeline even tho something hasn't changed, and you do so using the "always: true" statement. Basically Classic and YAML Pipelines behave the opposite one another.
Lastly, the time in the YAML Pipelines is expressed in UTC time zone and it is not possible to change time zone.
This is super flexible, way more than the UI.
Limitations
Keep in mind that there are certain limits on how often you can schedule a pipeline to run, put in place to prevent misuse of Azure Pipelines resources.
At the time of writing this post, the limit is around 1000 runs per pipeline per week.
Scheduled Runs
Before we close, I want to mention there is a way to check when your scheduled Pipelines will run next.
Just go to your Pipeline page, click on the Pipeline you want to check, click on the ellipses and the select Scheduled Runs
Conclusion
Alright, that's it for today.
Let me know in the comment section below what you use or plan to use the scheduled pipelines for.
References and Links
- Video with full explanation and examples about the Schedule trigger
- All the other videos in the Azure Pipelines Triggers series
Like, share and follow me 🚀 for more content:
📽 YouTube
☕ Buy me a coffee
💖 Patreon
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast
Top comments (0)