Just in a Windows Batch build step
C:\Program Files (x86)\InstallShield\2013 SAB\System\IsCmdBld.exe
InstallShield (R)
Release Builder
Copyright (c) 2013 Flexera Software LLC.
All Rights Reserved.
---COMMAND LINE OPTIONS---
--REQUIRED--
-p <file name> project file name
--OPTIONAL--
-r <release name> name of the release
-b <build location> full path to the output folders and files
-s silent build
-i <.ini file path> full path to an .ini file
-u upgrade only
-x stop at first error
-w treat warnings as errors
-l <Path Variable>="New Path" override path variable location
-v enable verbose mode
-n don't compile setup.rul
-q2 WINDOWS INSTALLER PROJECTS: build tables and refresh files
PROFESSIONAL PROJECTS: rebuild only changes since the last build
-q3 only compile setup.rul
-d <Name>=<Value> provide a preprocessor definition
-o merge module search path
-prqpath InstallSheild Prerequisite search path
--WINDOWS INSTALLER PROJECTS--
-a <product configuration> name of the product configuration
-c <release configuration>
COMP = Files compressed into .msi file;
UNCOMP = Files remain uncompressed
-f <release flags>
-e <Y/N> include Setup.exe in the build
-y <Product Version> version number in the format xx.xx.xxxxx
-m <CUB file> name of the CUB file to use to validate the package
-q1 build tables only
-t Microsoft(R) .NET Framework path
-h skip upgrade validators
-g minimum target MSI version
-j minimum target Microsoft(R) .NET Framework version
-z <Property=Value> set Property to Value in built MSI
--WINDOWS INSTALLER PATCHES--
-patch_config <patch configuration> patch configuration name
For more information on command-line parameters, please see the Help Library.
From: [email protected]
[mailto:[email protected]] On Behalf Of Chanda Norton
Sent: Thursday, June 05, 2014 12:17 PM
To: [email protected]
Cc: [email protected]
Subject: Re: Question on how to structure jobs for integration versus release
to QA builds.
wow...this is by a script I assume...a "post build step?"
On Thursday, June 5, 2014 8:32:40 AM UTC-4, rginga wrote:
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: [email protected]<javascript:>
[mailto:[email protected]<javascript:>] On Behalf Of Chanda Norton
Sent: Thursday, June 05, 2014 8:05 AM
To: [email protected]<javascript:>
Cc: [email protected]<javascript:>
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 [email protected]<javascript:>.
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
[email protected]<mailto:[email protected]>.
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
