In the past when I’ve set up Jenkins to look for version control changes every second by using the cron format of “* * * * *” (or something like that). When you do this, it gives you a warning and asks if you meant to say something like once a day.
My question is, why would checking once per minute ever be a bad thing? The only bad aspect that comes to mind is that it may be a performance issue. Otherwise, I would want my continuous integration server to always be checking for changes as frequently as possible so that I can know as soon as possible if an error got introduced. Is there a perspective I’m not seeing?
8
There are two things here – the client (in this case Jenkins) and the server (svn or git or something else).
As the client, asking every minute can consume a bit of resources – network and disk on the server, not to mention its own internal builds that compete with local resources for checking if anything has been updated.
At the server side, having a half dozen projects that get polled every minute can likewise be consuming in resources (disk and network) and can start to contend with other client updates (like your developers).
The thing is, if you want to start the build as soon as possible, there are other options for this. You can do a push instead of a pull. For example, on Stack Overflow: Jenkins CI: How to trigger builds on SVN commit and How to configure Git post commit hook in which the act of pushing a commit to the server will trigger a Jenkins build. It will never need to poll (much less every minute) to see if it needs to build because the server tells it to do so when it needs to.
As a follup to all this, I would suggest reading Polling must die: triggering Jenkins builds from a git hook which takes a more opinionated take on the issue.
One should look at the reason behind the desire to have the server polling every minute. This is what Jenkins, in part, seeks to address with the warning. If you want “building as soon as a commit happens” then hooks are the best technology to use for both the build server and the source of the data.
On the other hand, on many projects, a delay on a build isn’t as big of an issue as a delay of a few minutes would make it out to be. On several of the projects I’ve worked on a full test and analysis (as done on the CI server because it took too long to run on a developer’s machine) took a good 10-15 minutes if the build server wasn’t being taxed with other builds at the time (all the unit tests and static code analysis on a 1.5M SLOC project, then fire up a HSQLDB and jetty instance and run another set of tests…). Doing the polling every half hour was more than sufficient (and if a developer wanted the build to start now so that it would be done before he or she wanted to go to lunch or leave for the day and know with confidence they wouldn’t incur the wrath of a broken build upon return… well, there is always the “build now” button)
5
I’m not sure the polling resources argument is compelling. It’s a relatively efficient operation on most version control systems, especially if you’re just checking and not actually downloading the changes yet. Although, a push notification is certainly preferable.
Usually it’s the building resources that are the limiting factor, depending how frequently commits happen and how long your builds take. If you start a build too frequently, and your build nodes max out, that can increase the average latency to get results, especially at the busy times. Also, what can happen is a commit breaks the build, but by the time you get the results, you have several later builds broken by the same bug. This conditions developers to pay less attention to the CI server.
So if you happen to have fast builds and your build nodes never max out, by all means increase the polling frequency. If your build nodes are always maxed out and commits always break 3 or 4 builds before you even know it, then decreasing the polling frequency can help.