I am fairly new to Jenkins and I am trying to figure out the best approach for designing a CI process for Jenkins. We also want to use Jenkins for building release milestone and release candidates. This is for a .NET project and we are using a MSBuild, Ant, Ivy, and Subversion (the SCM). The build does everything from download source code for several applications, including installation bootstrappers and Wix projects for creating Windows Installer packages. About 17 projects from building the initial source code and installation bootstrappers to building MSI packages and then creating ISO CD images. So far I understand that for integration builds, its best to build at the HEAD revision (or latest revision for that project as Jenkins does) in version control, but for a Release candidate to QA its best to build at a fixed revision. I have figured out how to pass a Subversion revision between projects using the EnvInject plugin, a snippet of Groovy, and parameterized builds for this. I figured out how to get a single project to download the latest revision or a fixed one that you enter for a parameter.
The problem lies in if you want to use the same job to build at a fixed SVN revision versus the latest as for integration builds. You now seem to have a schizophrenic job that changes personalities viz-a-viz whether it is building at a fixed or latest revision and what svn revision if any to pass to the download stream project, and the fact that is has a single workspace that may be at the latest rev for that project (if for integration) or at a fixed rev for the release candidate build. You have 1 job that can behave in 2 different modes yet still having a single workspace. When you do your release candidate build, it seems that you would want prevent these jobs from automatically checking out the latest rev as in a CI type mode just after the build is complete and someone has just checked in a new rev for one of the projects. For the release build, I am experimenting with calling the jobs manually using the Build Flow Plugin or Multijob plugin in, passing the SVN revision to each job. I guess the best way to do this is to have 2 jobs for each project, one for CI and the other for an end-to-end release candidate build. I know that this is an open ended type of question, but I am looking for the "best practices" to use here. At least our jobs for the most part just download code and call some build scripts that are part of each project. I would like to know if I am on the right track. It's more "DRY" to use the same job for integration and release candidate builds, but it seems that there are issues that introduce more complexity than needed. Thanks, Aris Green
