If you are talking about the InstallShield plugin, that was a very recent addition done by a grad student. It’s reliability might be suspect. I create MSI’s by directly calling InstallShield’s command line IsCmdBld.exe. I don’t know about ISO’s.
From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Chanda Norton Sent: Thursday, June 05, 2014 8:05 AM To: jenkinsci-users@googlegroups.com Cc: aris.gr...@gmail.com Subject: Re: Question on how to structure jobs for integration versus release to QA builds. 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 jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- 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 jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
