Using Jenkins as an automation dashboard, part 1


The most common automation tool on Unix-like system is cron. It seems to be convenient at first, but it has a number of drawbacks. There are just too many things to worry about:

  1. If some command fails, there’s no notification.
  2. A command might not fail, but hang. No notification about that either.
  3. And in addition to that, a slow running or hanged command might cause multiple instances of the script simultaneuosly. Which, in some cases, might be disastrous. So you have to add lock files, pid files, etc.
  4. Even if you do add a notification in the script, it might not be sent due to, say, mail server being down.
  5. You need to store script logs. And to rotate them, too.
  6. And, if something goes wrong, and you do get a notification, then you have to log into the problem server, find the log, search it for problems, to see what’s really happened.

All this isn’t impossible to solve with enough scripting. But it’s tedious and time consuming.

It would be rather nice to have a bird’s eye view of your tasks instead, wouldn’t it? Current state, logs, history of launches, launch on demand, execution time control, chaining tasks, etc – all one click away in a browser? Well, Jenkins CI is just that. It solves all those problems.

Move any task that you care about to Jenkins, and sleep well – you will know when there are issues. It’s so much more convenient than scavenging servers for logs.

Stay tuned for second part – proper Jenkins configuration for automation.