You can schedule Drone CI pipelines to run on a cron schedule using the trigger section of your .drone.yml file.
Let’s see this in action with a simple pipeline that just logs the current time.
kind: pipeline
type: docker
name: cron-example
steps:
- name: log-time
image: alpine
commands:
- echo "Pipeline triggered at $(date)"
trigger:
cron:
- "0 * * * *" # Run every hour at the top of the hour
- "0 0 * * *" # Run every day at midnight
This pipeline has one step, log-time, which uses an alpine Docker image to execute a shell command. The commands section contains echo "Pipeline triggered at $(date)", which will print the current date and time when the pipeline runs.
The key part here is the trigger section. Under trigger, we have cron. This is a list of cron schedule strings. Each string follows the standard cron format: minute hour day-of-month month day-of-week.
"0 * * * *": This schedule means "at minute 0 of every hour, every day of the month, every month, every day of the week." So, this pipeline will run at 1:00 AM, 2:00 AM, 3:00 AM, and so on, every day."0 0 * * *": This schedule means "at minute 0 of hour 0 (midnight), every day of the month, every month, every day of the week." This will trigger the pipeline once a day, precisely at midnight.
Drone’s cron trigger works by polling the Git repository for changes. When a cron schedule matches the current time, Drone checks if the Git repository has been updated since the last cron-triggered run. If there have been no changes, Drone will skip the pipeline execution to avoid unnecessary runs. This is a crucial optimization that prevents redundant pipeline executions when your code hasn’t changed. It’s not just about time; it’s about time and change.
To illustrate the internal workings, when you define a cron trigger, Drone internally registers this schedule. It then has a background process that periodically checks the system clock against all defined cron schedules. For each matching schedule, it performs a Git fetch operation to get the latest commit hash. It then compares this new commit hash against the commit hash from the last time that specific cron schedule successfully triggered a pipeline run. If the hashes differ, it initiates a new pipeline run. If they are the same, it marks that cron trigger as "no changes" and waits for the next scheduled check. The "last successful run commit" is stored by Drone for each repository and cron schedule combination.
The cron trigger is not the only way to schedule pipelines. You can also use the schedule trigger, which is more flexible and allows for more complex scheduling logic, including intervals and specific dates. However, for simple, recurring tasks like nightly builds or hourly checks, the cron trigger is often sufficient and more straightforward.
When you set up a cron trigger, Drone relies on the system’s time. If your Drone server’s clock is not synchronized with a reliable Network Time Protocol (NTP) source, your cron jobs might run at unexpected times or not at all. It’s essential to ensure your Drone server’s host system has accurate timekeeping.
You can also combine cron triggers with other trigger conditions, such as branch filters. For example, you could schedule a pipeline to run only on the main branch using cron and branch.
kind: pipeline
type: docker
name: cron-example
steps:
- name: log-time
image: alpine
commands:
- echo "Pipeline triggered at $(date)"
trigger:
cron:
- "0 * * * *"
branch:
- main
This would ensure that the pipeline runs every hour, but only if there have been changes on the main branch since the last cron trigger.
The most surprising aspect of Drone’s cron trigger is its reliance on Git commits for execution. It’s not a simple timer; it’s a timer that also demands a change in your codebase. This is a deliberate design choice to avoid wasting resources by running pipelines when nothing has fundamentally changed. Many users expect cron to simply fire at a specific time, regardless of code. Drone’s approach is more efficient but requires understanding this subtle dependency.
The next concept you’ll likely explore is how to manage secrets and sensitive information within these scheduled pipelines, especially if they need to interact with external services.