Why do build servers poll for changes instead of SVN firing off an event (or a post-commit step) that tells the build server to start a build? It seems terribly inefficient to poll for changes, especially when the number of projects increases and the polling period is set to a very low value (for example, 30 seconds).
+1
A:
Hudson also supports build via post-commit trigger. See:
http://wiki.hudson-ci.org/display/HUDSON/Subversion+Plugin
Post-commit hook
Hudson can poll Subversion repositories for changes, and while this is reasonably efficient, this can only happen up to every once a minute, so you may still have to wait a full minute before Hudson detects a change.
To reduce this delay, you can set up a post commit hook so the Subversion repository can notify Hudson whenever a change is made to that repository. To do this, put the following script in your post-commit file
. . .
(There are examples for Linux/Windows.)
William Leara
2010-06-16 19:31:19
A:
Generally builds are scheduled to kick off at a specified time interval e.g. 3AM every day. There some logic can be placed to see if there are changes then only build the project but commonly they don't check and builds are made every day (nightly builds)
As for your suggestion which is a good one, I would say that it doesn't look feasible to kick off a build on every commit. Many a times the developer doesn't commit their changes in one go and prefers incremental check-ins. Also it gives some peace of mind to know when the build process will kick off so that you at least have a chance to tidy up things in case of wrong commits. With your suggestion a wrong commit results in a wrong build.
Monis Iqbal
2010-06-16 19:34:09
First, continuous integration means building *continuously*, ultimately after each change, not just once per day (so called daily builds). Then, Hudson has a *quiet period* allowing to delay the build after a commit (Hudson will wait N seconds before to trigger the build). Finally, I have to say that doing non-atomic commits is a very bad practice.
Pascal Thivent
2010-06-16 20:26:04
+1
A:
It seems terribly inefficient to poll for changes, especially when the number of projects increases and the polling period is set to a very low value (for example, 30 seconds).
Polling is inefficient and it doesn't doesn't scale at all. If your VCS has support post-commit hooks, you should prefer this mechanism. Hudson exposes an URL to trigger a build, wget it from the post-commit script (and configure an appropriate quiet period).
Pascal Thivent
2010-06-16 20:13:27