I am working with about 30 or so projects in Hudson. Right now they all build automatically on a commit. Is there any way to switch all of the projects between trunk and a branch while maintaining the ability to build on a co开发者_JAVA技巧mmit?
I have though of making the builds parametrized to specify the branch but this breaks the automatic builds.
Well, you have a couple of options:
1) You could use parametrized builds: you can still have automatic builds, but one of the options will be default (either trunk or branch will be default)
2) Have separate builds for each project, for trunk and branch
3) (this is how I have it set up at our place) Have two build servers: one for trunk projects, and one specifically for branches.
I'm not entirely sure how you intend to use the "switch," but I guess it depends on how you use branches. (In our setup, branches that have continuous builds tend to be long lasting projects or releases. So we set up builds for each branch that are separate from the trunk builds. If your branches are long-lived, that's the approach I would recommend.)
There are several ways to approach this:
Write a script to re-configure (or copy) the jobs through the Hudson Remote API. If you look at http://your-hudson/job/JOB_NAME/api, you can see more instructions on how to submit a new job configuration. That an automated way to edit the
scm/location/remote
property.Use a post-commit hook in your scm to run the parameterized build. A post on the Hudson Labs blog describes how to set up a subversion post-commit hook (for the purpose of pushing commits rather than polling). You'll need to do a little more work in your script to determine what to build. This solution seems pretty fussy to me.
+1 or sagar: On the first thought, I would have suggested the first option as a solution for bobnix' issue.
However, the question a few more times, I am not sure what he actually wants to accomplish. If he wants to trigger builds either from branch or trunk, than he might be better off with the post commit hook. +1 for Dave B. (solution 2)
If he just wants to build for some time the branches instead of the trunk, than the best solution would be Dave's number 1 solution.
There is another option, that Bobnix actually want's for some time build the branch, but spares the efforts to set up a new job. The solution would be to reconfigure the existing job until it's time to switch back to trunk. If there is little development, when there is development on the branch, then this might be a valid train of thought. However, since copying is so easy you should be better off, just to copy your trunk job and adjust the scm to branch. When you don't need you branch anymore, just delete it.
精彩评论