Subversion Post Commit Hook support

Is it possible to have builds triggered by a post commit hook in subversion rather than using SCM Triggered Automated Builds which I assume polls subversion for changes?

Ideally it would need to operate like jenkins - call a buildmaster url from subversion post commit hook passing the repository/path that has changed and have buildmaster figure which project needs to be built.

I guess I could use URL triggered builds from SVN post commit hook but there would be alot of maintenance of post commit hooks required to support that as new project and jobs added.

How often does it BuildMaster poll subversion and is this configurable?

Product: BuildMaster
Version: 4.6.2

You can trigger them with a post-commit hook, and the easiest way would definitely be the URL-triggered builds.

You can configure how often it's triggered with the ScheduleExecuterThrottle setting (value is in minutes) in Advanced Settings.

Can I make a suggestion for the Subversion/Source Control plugins?

Updating commit hooks everytime a new BM job or SVN project is created or renamed is problematic - most developers don't have the required access.

I believe the Jenkins implementation strikes a very nice balance here - the post commit hook calls a single end point and that service identifies the jobs affected and triggers them.

Any chance of implementing something like that?

Short answer: yes.

Let's definitely connect soon; we're looking to revamp some of our most popular extensions (Jenkins, Subversion, etc), and want to make these integrations much smarter and easier to use.

I'd love to talk about this!

In short my immediate requirements for Jenkins and BM integration:

I plan on using Jenkins to do the build and testing:

the number of plugins
developers and testers comfortable with it and don't want to change
the cost of ramping up the number of users required to do all this on BM make it very attractive to keep these tasks in Jenkins.

I'd like to use BM for deployments and orchastration

Workflow would look something like

SVN Commit -> Jenkins Build/Unit Test/Code Analysis/Notify BM -> BM Import Jenkins Artifact/Deploy First Env/Tell Jenkins to run test suite

Current Issues:

Security as above
I want to sync release and build number in artifacts I build in Jenkins with those in BM. Using API I can get release number from BM into Jenkins. I was planning on using Build Importer: Jenkins in Build Step as in UI this defaults to "use Jenkins build number" and fails the build if out of step. However url trigger build behaves differently... Its difficult to use the API to notifiy BM as I have to wait for Jenkins to archive artifacts and that requires doing notification in a post build action.

On that orcastration plan: I am also toying with the idea that BM should control everything including notifying Jenkins to run the build task.

NOTE: The security thing I mentioned in above post is actually on another question: http://inedo.com/support/questions/2852. I've had to enable anonymous access to Jenkins to allow BM to trigger Jenkins jobs.

The workflow would now look like this:

SVN Commit
BM Call Jenkins build job and wait till complete / Import artifacts
BM Automatically Deploy to First Environment / Call Jenkins automated test suite job and wait till complete
BM Maunal/Automatic trigger to subsequent environments

Pro's

This hugely simplifies things like picking up release and build numbers in Jenkins. Currently I have a lot of groovy scripts calling BM api's (great api's btw!) to tie Jenkins, Artifactory and BM together. Simple is sounding very good right now!

Con's

A little more convoluted process before the build job actually runs
If multiple commits made in short time then potential for BM and Jenkins to be out of sync with what revision getting built. (Possibly could pass revision number through to Jenkins? What would BM do if got multiple triggers while waiting for first job to complete?)
Jenkins also has concept of a quiet period which is quite nice if developer makes a couple of commits rather than committing all changes in one it. (Very minor feature which I don't mind loosing)
Developers used to kicking of Jenkins job manually at times, generally to speed up the feedback process - but that is to work around the quiet period which we don't really need.
We prefer to trigger jobs with a subversion post commit hook rather than polling - very easy in Jenkins, quite complicated in BM. Would be nicer to follow the Jenkins model: notify a single url and have that determine which jobs access that repository and trigger them.
If SVN repository name changes now have to update in two places.
How support building branches, don't really want to configure new job per branch (don't handle this currently, just a what if question)

Any advice on the best way of integrating these tools, or comments on the merits of any of my suggestions greatfully recieved :-)

I appear to have hit a show stopper on the full orchestration approach:

There seems to be a limit on how many jobs will run in parallel in BM and we cannot afford to sit around waiting for a spare executor after a commit. Therefore it seems its back to the more complicated solution whereby Jenkins does the build (rquesting release number from BM) and the notify BM to import and deploy the build :-(

I've figured out what I would like to see and its an approach I've seen other tools take.

I think you need a BuildMaster plugin for Jenkins that I can add as a build step in Jenkins to:

Import ReleaseNumber as a variable
Trigger a BuildMaster Job and a) send selected artifacts to BuildMaster, b) set the BM build number to the Jenkins build number (I just like to keep things in sync for traceability)

Workflow SVN Commit -> Jenkins Build -> BuildMaster: Import Sent Files

I'd then deploy to first environment (using the BM post build step action) which would do the deployment and then call test job in Jenkins to verify deployment and/or perform regression testing.

I've got most of this working using groovy scripts, but it would certainly improve things if wrapped in a plugin.