Most developers are probably familiar with Jenkins, the lightweight and venerable Continuous Integration framework. It has been widely used in the software community for years to automate and deploy software builds. This post is not about that, nor the many benefits of Continuous Integration. Instead, I would like to discuss a couple of other ways to leverage Jenkins to simplify and automate other tasks in your software operations.
A Common Scenario
If you are a technical person, at one point or another you have probably been asked to create and execute a one-off piece of software to accomplish something important to a non-technical person. Bound in equal parts by duty, a neighborly spirit, and a heightened sense of adventure you’ve always done your best to satisfy these requests. Often your solution to these requests manifests as some code that is launched from a command line. And because your customer in this scenario is non-technical they aren’t able to execute that. Should the one-off request ever become a five-off, you both might be looking for an easy way to make this a self-service operation.
Expose Those Command Line Scripts
Enter Jenkins, which allows you to provide access to a command line script that can accept any number of arguments. You can then make it accessible to anyone via a simple web interface. Jenkins is easy to download and install. Once that’s out of the way, let’s walk through the steps to expose a command line script. I’ve created a simple example script called report.sh (available here) that we can work with.
From your Jenkins front page, click “New Item”.
Now give your new job a name and select Freestyle Project. Click “OK”.
If your script accepts parameters, check “This project is parameterized” and configure them.
Lastly, add a Build step of Execute shell and enter your command line incantation, referencing any parameters as necessary. Click “Save”.
There’s a bit of a quirk with Jenkins in that it won’t create a workspace for your project until you have run at least one build. So, we run a build, knowing that it will fail and won’t actually do anything. But hey, it’s free software. Anyway, once the project workspace is created, move your script into it and then we’ll be ready to test it’s execution using Jenkins. Click “Build with Parameters,” fill in the arguments, and click “Build.”
You can monitor the task by watching the console output. When you have verified that it does what you need it to do you just have to give access to your non-technical friend. And now they will be able to execute it whenever they need to, even when you are unavailable.
Schedule Jenkins Task Execution
The standard Linux task scheduler, cron, is notoriously frustrating to work with and provides very little in the way of monitoring or reporting on tasks. Jenkins provides a much better environment for scheduling tasks. And you’ll get a detailed execution history and plenty of plugins for integrating with third-party tools. It understands the cron syntax for defining a schedule and also provides some nice syntactic sugar (e.g. @hourly or @daily) to make it easier to read.
To set up a Jenkins task to run periodically go to it’s configuration page and check “Build periodically.” Then enter the schedule you want the task to run on.
Now, whenever you want to check in on the results of the a scheduled task execution, you can find the entire history all in one place.
Conclusion
At it’s core, Jenkins is a task execution platform. And it provides a lot of different ways to run those tasks. And they don’t always have to be bundled up in a software build process. So whether you want to transfer log files from A to B, poll a repository for some data to download, or allow your non-technical friend to run that report again, Jenkins has you covered. Have you used Jenkins or another framework to execute tasks? What kinds of tasks are you struggling to automate?