This article is about CRON jobs and how we configure Jenkins jobs using different CRON options. It highlights the fundamental role of CRON jobs, a bit of their history from version 7 UNIX to the later version of UNIX system V.
Introduction
Two weeks ago, it was an unusual day while working with my team, we all were trying harder to establish the build for the demo to our client and my part to make the Jenkins job work properly for the sake of smart automated testing of the product. It was the first time I was configuring a Jenkins job from scratch where I needed to set up the slave machine, the number of executors and available options to schedule the Job accordingly. The most interesting part is to schedule using Build Trigger options which work with CRON job to trigger the job periodically at the specified time. Since then, I thought of writing an article about CRON itself and its potentially helpful usage in the Jenkins job.
In this article, I’m going to highlight the fundamental role of CRON jobs, a bit of their history from version 7 UNIX to the later version of UNIX system V. The windows version of CRON jobs and few other worthy points to discuss.
CRON & Its Use Cases
Before talking about technical stuff like CRON syntax and how it works, etc., let's know who should you or might you be thinking about CRON job.
Imagine, your doctor has recommended 60 ounces of water per day (normally, 1 liter is about 33.xxx ounces so 60 ounces will be around 1.8 liters.), but if you’re normal you would not drink it all at a time, rather you will slice and schedule your intakes suitably. But what if you’re bad at maintaining the routines and amazing at forgetting the things. So, better to automate the process to remind you what and when you have to do your tasks?
Similarly, when it comes to software, utilities, services and other EOD and SOD tasks, you need to schedule some repetitive jobs to trigger some pre-specified commands automatically, you can schedule any task or job to run after fixed hours or periodically throughout the day, number of times in a month, on specific days or dates, etc. Here’s what CRON job play the role more suitably. They are time-based task scheduler which is being used for almost every time of scheduling. For instance, to download the reposts daily at 1:00 AM, to run the DB commands and re-start the servers whenever machines get rebooted, to execute some UI or functionality testing scripts throughout the night and on and on.
CRON Syntax & Working
CRON syntax, commands and understanding could be a little bit challenging if you want to understand the its functionality for the Linux operating system, that how CRION utility manages the scheduled tasks using concrete command line syntax, how the Crontab files are edited and how Linux interprets these commands and scripts and trigger the jobs periodically. In logical terms, CRON is a daemon that's why it needs to be started only once and then it will lay asleep or inactive until the next triggering time reaches. There are few other sciences too which are good to consider unless you're not using CRON for Jenkins Job scheduling like root and other users of Crontab file which is the actual file holding the job read by CRON. This file gets generated at the time of OS installation. Since this article has to do all with the Jenkins job scheduling via CRON (not with the CRON lifecycle in UNIX based environment), I'm concluding the explanation at the very shallow level here.
CRON in Jenkins
Navigating to Build Trigger tab of your Jenkins job Configure option, you will have the checkbox for build periodically and SCM Poll, these are the options where you need to know and understand the CRON syntax and its role while configuring your Jenkins Build.
These are the some of the most powerful options of the Jenkins job configuration which make it one of the most flexible continuous integration systems around.
Before explaining further, the use of CRON job in Jenkins Job build, I preferred to share the exact description of this feature from one of the Jenkins job interface itself, which is self-explanatory. Jenkins gives two slightly different options to build your job periodically the question is:
- If you require to execute your job every time when something new is pushed into your repository since the last build, OR
- You want to trigger the job at some fixed or periodic time intervals of your choices, regardless of the fact that if something is changed or not in your repository.
In the first case when you need to trigger your job as per the changes of your version control system, i.e., GIT, SVN or any other, you will be choosing Poll SCM option from the build trigger tab. Which could be tackled either by writing CRON job to check the changes in the repository after every 10 or 15 minutes of you can use some plugin or utilities which will automatically signal your job when your repository will change.
In the next case, you have nothing to do with the changes in your version control system rather you want to trigger your job depending on the requirement of your job. As I've mentioned before, if it is a server related job, then definitely its triggering time will be different if it's just about reported downloading and dumping into the DB then your choice will be built periodically option in the build trigger tab and I'm going to explain the syntax right down here.
Demo: Creating and Running a Job
Consider creating a quick Jenkins job project which will run at 12:00 AM and delete all of your temporary files.
Move ahead and launch Jenkins either from localhost (localhost: port) or from your server IP where the Jenkins is hosted (ServerIP: port). Click on the ‘New Item’ and add either the Freestyle Project or whatever you feel feasible with, though in our case it’s a Freestyle project (DeleteTempDaily).
Figure 1: Creating the job in Jenkins.
Configure the job accordingly by adding the following details like job details, time to execute the job, build steps, etc.
Add the job details from the General tab.
Figure 2: Configuration of the job.
Schedule your build from Build Triggers tab by writing following CRON syntax and select ‘Build Periodically’ option.
Figure 3: Scheduling the job build.
Add the build step from the Build tab and write the batch following command to execute.
Figure 4: Writing the batch command.
Build your job to test if everything is working as you’ve expected, after doing this, you’ll have your build results like the following:
Figure 5: Job results after the build.
Next time your job will automatically execute at 12:00 AM since you have scheduled it to run at this time using CRON syntax.
So, that is how you can create and run a job using CRON timing.
Bonus: CRON Syntax
Syntactically, CRON contains 5 places for each time entry, thus a conventional one-liner syntax of the CRON template would be somehow like:
0 23 * * *
// Staged as
{Minute} {Hour} {DayOfMonth} {Month} {DayofWeek}
- Minute (0-59) – tells at what minute of the hour the Job should build.
- Hour (0-23 With 0 is the midnight) - tells at what hour the job should build in the 24-hour clock.
- Day of the month (1-31) - tells on which day of the month your job should build, e.g., 23rd of each month.
- Month (1-12) - tells the month when your job should build. You can number or name the month as well. i.e., April, May, etc.
- Day of the week (0-7 With 0 or 7 both being Sunday) - tells the day of the week when you want to build your job. It can also be a number or name like Mon etc.
For instance, you might be interested in scheduling your job at the following times:
- Every day 6 in the morning
- Every 20 minutes
- After every 4 hours
So the overall CRON job syntax would be like this:
// Every day at 6 in the morning
0 18 * * *
You need to make the first entry (minute) fixed if you want to work on the hour. The above expression means to run your job at the 0th minute of 18th hour DAILY without any specification of day, month or week. Now take a look at the following few more examples of the CRON.
After every 20 minutes
*0/20 * * * *
After every 4 hours
0 */4 * * *
// OR
0 0,4,8,12,16,20 * * *
In the first case, it will run at 0th minute, 20 minutes after, 40 minutes after means after every 20 minutes. 20 is the offset here which tells after how many minutes this should trigger.
Similarly, in the next example, the first entry (minute) is fixed and the second entry (hour) contains an offset which tells keep repeating it after 4 hours. In the next line, the less verbose and more readable syntax of the same CRON is also given.
Every day at 11 in the morning and at night both
0 11, 22 * * *
You can define the multiple values for same entry using a comma. Here, the hour place has two values, first for 11 am and the next for 11 pm.
Every Saturday and Sunday at 5 PM
0 17 * * 6,7
This will run every Saturday (6) and Sunday (7) at 5 pm (17).
Final Words
So far in this article, we have gone through the theoretical part as well as practical one of CRON. Where and how we schedule our Jenkins, a job using CRON and many interesting and useful examples to get your head around its syntax which seems to be the only complex things in its workflow and the rest is all easy to go and understand. For the sake of little hands-on practice and getting familiar with the syntax, you can visit these online CRON practice sites: https://crontab.guru/ and https://crontab-generator.org/.
History
- 6th May, 2018: Initial version
