Can Hudson be configured to build every revision?

I’ve started experimenting with Hudson as a build server. I’m using subversion and have it configured to poll every minute. The issue I’m seeing is that if a build at revision 10 takes 5 minutes and there are 5 commits during that time, Hudson will next build revision 15.

Is there a way to ensure every revision is built?

  • What are Jenkins best practices with building with Grunt and deploying with Capistrano?
  • Xcode Build server. Git operation failed
  • TeamCity: labeling VCS (Subversion) with an artifact's file version
  • SVN: Release branch and externals?
  • How to not include a class file with API strings in git, but still get it on a build server?
  • Travis CI with SSHpass to remote pull git modifications
  • Web (PHP) application deployment strategy
  • Hudson git error ssh
  • How to make travis-ci work with a local git branch instead of a specific commit?
  • How to convince jenkins to share a build number for several jobs?
  • Revert commit on remote branch without force pushing
  • 5 Solutions collect form web for “Can Hudson be configured to build every revision?”

    Hudson does not yet have this capability, but its been asked for a few times on the mailing list. See issue 673

    You have to do a few things to build exactly each revision:

    • add a REVISION string parameter to your job
    • append the ${REVISION} parameter to the repository URL,
      e.g.: https://server/path/myproject${REVISION}
    • set the name of the local folder to ‘myproject’ (see previous example), because the REVISION variable is only expanded in the URL, but when creating the folder, Hudson will not expand it, resulting in a folder named: myproject${REVISION}
    • trigger the parameterized build from the post-commit hook, like that:

      /usr/bin/wget \
      --auth-no-challenge \
      --no-check-certificate \
      --user=me \
      --password=mypasswd \
      https: //server/path/job/jobname/buildWithParameters?delay=0sec\&REVISION=%40$REV \
      -O /dev/null

    If you want to trigger a build manually, you have two possibilities:

    • if you want to build HEAD revision, you must leave the REVISION parameter empty
    • if you want to build a specific revision, you have to enter @NNN (eg: @1234).

    The @ sign is very important because all this trick relies on the fact that Subversion plugin interprets URL@NNN as get revision NNN from repository at URL. If you forget the @, Subversion will just say it can’t find folder https://server/path/myprojectNNN. That’s also why you have to put %40 between REVISION= and $REV in the wget command, %40 is the escaped character for @.

    In SCM part of build configuration you should have Build Triggers section and option “Trigger builds remotely (e.g., from scripts)”. According to help info next to that option you can script post-commit action so every commit would fire new build. As hudson has build’s queue you should have every revision built.

    Here’s a link that could help you: https://hudson.dev.java.net/build.html

    Here’s example how to start build job with parameters (see to my comment for details):
    http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build

    The key to make sure every commit is built in Hudson is “Parameterized Build” and ONLY IF trigger build with different parameter values, hudson will think it’s new build and should be held in build queue. Or it won’t be recorded by Hudson since it consider it’s meaningless build compared with previous one

    e.g. you can click “Build Now” to trigger build for three times and just leave the build para as “null”. you will see only first two builds are in Hudson queue. The third one will be ignored 😛 cool but it’s really bad that it’s not found in some document but with my experiments for times 🙁

    I took fchateaus approach above (thanks man!) and modified it to work with Mercurial.

    You will need to edit .hg/hgrc on the central server, and put in a changegroup hook. Keep in mind that changegroups only set the first changeset to the HG_NODE environment variable, so you have to do a hg tip to grab the real tip node and pass that along via URL instead. A bit of a trick to do in a one-liner, but I figured it out.

    This is what you would do for Hudson running on Windows.

    [hooks]
    # this uses wget to hit the hudson url responsible for starting a build - %HG_NODE% only gets first changeset of changegroup, so use hg tip to grab changeset most recently added instead
    changegroup.hudson = for /f "tokens=*" %G IN ('hg tip --template {node}') DO "C:\Program Files (x86)\UnxUtils\usr\local\wbin\wget" --non-verbose --spider http://HudsonServer:8080/job/{Repository}/buildWithParameters?HgRevId=%G | ECHO Result of Hudson Polling Request For Node %G
    # TODO: when Hudson implements polling with parameters, change to something like this
    #changegroup.hudson = for /f "tokens=*" %G IN ('hg tip --template {node}') DO "C:\Program Files (x86)\UnxUtils\usr\local\wbin\wget" --non-verbose --spider http://HudsonServer:8080/job/{Repository}/polling?HgRevId=%G | ECHO Result of Hudson Polling Request For Node %G
    
    Git Baby is a git and github fan, let's start git clone.