hi, how did you get Jenkins to create windows installer packages. There was an MSI plugin, but it crashed my Jenkins server when I installed it. I would need to build MSI packages...also how do you create the ISO images...?
On Monday, December 31, 2012 4:56:55 PM UTC-5, Aris Green wrote: > > 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 > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
