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?
Best Answer
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)