0

What I need is a SVN post-commit hook that must be able to create (not to just trigger the run) its own Jenkins Job (if the revision ID is 0), and it has to be executed on multiple project. Basically, each project must be able, using this hook, to add its own job in Jenkins the first time it's committed. What I need to know is how to give to Jenkins the repository URL for each project, using always the same hook.

RVKS
  • 147
  • 3
  • 16

1 Answers1

3

When you run a post-commit hook, the committer has to wait until the commit is complete -- which means waiting until the post-commit action itself is complete. If this takes too long, and too long can be a few seconds, the users will revolt. Imagine every time you do a commit, the commit takes 15 extra seconds. Fifteen seconds of you sitting there not knowing what's going on. How long will the user wait until they start trying to terminate the commit?

You can duplicate Jenkins jobs and update the config.xml of a job through the Jenkins REST API. It's not trivial, but it's possible. However, this is not the mechanism that you want to use.

Instead of having dozens of Jenkins jobs that build the project's sub-tree in your repository, have a single Jenkins job that builds the project's sub-tree that was modified.

Imagine your Subversion URL for project foo is http://svn.vegicorp.com/projects/foo and your Subversion URL for project bar is http://svn.vegicorp.com/projects/foo. You could setup a Jenkins job to monitor http://svn.vegicorp.com/projects, then see whether foo and/or bar have been modified, and then fire off the build for that particular sub-tree. When someone creates project http://svn.vegicorp.com/projects/fubar, Jenkins will watch over that project too since it's already looking at http://svn.vegicorp.com/projects.

You can use the Build Name Setter Plugin to set the name of the build to the sub-tree that was built. This will let you see which builds were for which projects.

This should be much easier to setup in Jenkins than trying to create on the fly Jenkins jobs.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • Thanks a lot, very useful. It really seems much easier compared to what I had in mind. So if I understood well, what I need to do is to create a job and set the SVN URL to the one containing every project I want to build and test. Then, set "Repository depth" to "Infinity" (so that every project contained in the sub-tree will be picked up), and simply configure this job as I would like to do with every job. Right? This would be awesome. – RVKS Jul 20 '15 at 17:31
  • I take it that your URL structure in your repo would be something like `http://server/project/branches` or `http://server/branches/project`. Let's say it's `http://server/branches/project`. You check for `http://server` for changes. Then, you can see what branch and what project was changed and build that. Use the build name setter plugin to specify the branch and project built. I take it that all of your projects build the same way. – David W. Jul 21 '15 at 00:29
  • Ok, thanks a lot, just a final question: I also need to send an email to the committer who eventually will cause a failure in the tests, but, if he caused for example 5 errors in one project and another committer caused 3 errors in another project, I need them both to be emailed with the correct number of errors that they caused. I'm sure this would work in the way I wanted to create Jenkins jobs initially, but will your method do that too or will both committers be warned of 8 errors (the sum of all the errors in the job)? – RVKS Jul 21 '15 at 07:39
  • Plus, are you sure that, when a new project will be created in the monitored tree, the build and test will be triggered only for the new project and not for the entire Jenkins job (so all the projects contained in the repository)? – RVKS Jul 21 '15 at 09:58
  • Jenkins can automatically email the commiters of the code on failures. If there is more than one commit from more than one committer, all committers will be emailed. However, normally, Jenkins will do a build with each commit detected, so there's only one committer. – David W. Jul 21 '15 at 18:42
  • You are detecting any change in the repo. Then, you can use a shell script (like BASH or PowerShell) to process the changes and figure out what was changed, and build that. That is, your master build script will figure out what to build. You're looking at the whole repo and all projects whether modified or added. Jenkins will give you the Subversion revision, and you can use `svn log -r... -v --xml` to find the files that were changed, see what project these were, and then run your build script for that project. – David W. Jul 21 '15 at 18:46
  • Not knowing how your projects are structured, the language you're using, or how you're doing the build, it's hard to give you more details. The point is that you're detecting any change in the repo, looking at the `svn log` to see what was changed (added or modified files), and then firing off a build to build all projects that were changed. You can use the Build Name Setter Plugin to label the build, so you can see what branch and projects were build. – David W. Jul 21 '15 at 18:48