Note
that the way things are written right now, the packaging instructions
for the application must exist in the 'build' image. If you try this
out and it cannot find the packaging instruction class, they I suspect
you have it in the application config map rather than the 'build' config
map.
There are
very few components to our solution. You will need to supply your own
abt.ini with the reference to your library and any parameters you need.
Otherwise in the attached zip file you will find
- abt.cnf: The initial image startup script used to create the build image. This takes the following command line options
- -user=yourusername that will own the image. Must be a user in the library.
- -map=MainConfigMap that points to the features you need in the main build image
- Optionally -xdmap=XDConfigMap if you need an XD image listing the config map for the features to put into the XD Image
- UNIX.txt:
A text file used by the XD image creator that defines the properties of
the XD image. Note that while this file has a place to define
InstalledFeatures, this list is ignored by the XD subsystem. Instead,
you will find a bit of code in abt.cnf that does 'xdImage
installFeatures:' that will load features not in your config map
- build.cnf:
The image startup script used by the builder image to create your final
application images. This takes the following command line options
- -map=ApplicationConfigMap which is your application config map
- -pkg=PkgInstructionName which is the name of the packaging instruction to use
- Optionally
-ver=<version> which is the version number of the application
config map to load. If no version is supplied, the latest edition of
the config map (versioned or not) is built. Else the latest versioned
config map which has the string V<version> in it is built.
- create_builder.cmd:
A sample windows batch file to make it quick to create new builder
images. You will have to edit this for your situation.
- build_image.cmd:
A windows batch file to use the build image to create application
images. You might have to edit this for your situation.
We
use a 3 segment version number for our config maps.
V<major>.<minor>.<patch>. If you use a different
system you will need to change the edition detect: logic in build.cnf
The
build.cnf looks at the type of packaging instruction supplied on the
command line. If it is an XD packaging instruction, the config map and
version is loaded into the development image and XD image and the XD
packager is invoked.
Running
To
create a build.icx image used to build application images you can put
the attached files into a directory and edit create_builder script or
run
COPY /Y "C:\Program Files (x86)\Instantiations\VA Smalltalk\9.1x86\newimage\abt.icx"
"C:\Program
Files (x86)\Instantiations\VA Smalltalk\9.1x86\nodialog.exe" -iabt.icx
-ini:abt.ini -loutput.txt -user=yourusername "-map=MainConfigMap"
"-xdmap=XDConfigMap"
TYPE output.txt
To create an application image, you can then use this build.icx and run build_image.cmd which basically does
"C:\Program
Files (x86)\Instantiations\VA Smalltalk\9.1x86\nodialog.exe"
-ibuild.icx -ini:abt.ini -loutput.txt "-map=ApplicationConfigMap"
"-pkg=PackagingInstructionName"-ver=X.X
TYPE output.txt
Outputs
You
will (hopefully) get all the outputs configured in your packaging
instruction. In addition, we generate an HTML snippet containing the
description of the config map edition being built. We use this as part
of our release note generator for our releases.
Jenkins tips and tricks
Jenkins
cannot consume the -lCON output generated by abt,exe/nodialog.exe. It
assumes that the output it will grab is generated directly by the
command that is being executed. To get around this, I tell abt.exe to
write to a file (output.txt) and once the operation is completed I
output this file to jenkins. This means that the console output in
Jenkins is not updated while an image is being built - only at the end.
The
second tip I can give is that it is not possible (well I couldn't find a
way) to run the packager in a purely headless mode. This means it
requires a desktop to work. Jenkins only runs a slave build on a
desktop if the agent is run from a desktop - and not as a windows
service. While the build will still run if your run it as a build job
on a windows service jenkins slave, you will not be able to resolve any
issues with the build job (as you will have no UI).
We
have one build job to create the build.icx which is then archived as an
artifact by Jenkins. The application image build jobs then Copy this
artifact as part of the application image build jobs. The output images
are then fed to the build jobs we use to package our total application
(eg with the VA smalltalk runtime DLLs and all our support images and
stuff).
Issues
- I've
not found a way to guarantee that the process 'exits' on failure. Any
walkback inducing error will launch the interactive debugger. I've
tried to intercept most prompts and errors such that Jenkins is told of
the error, but definitely not all. If nodialog.exe does not 'exit' then
Jenkins waits forever for it to finish. The only way to 'fix' this is
to login to the desktop running the jenkins slave and answer whatever
prompt is being displayed in the VA Smalltalk UI.
- I've not
found a way to intercept the XD transcript so that it appears in the
jenkins job output. There appears to be lots of code inside the XD
system that assumes the XD transcript is a CwShell style window. So
right now, you cannot see progress of the XD portion of the build. If
anyone has a tip or trick to fix this, I'd be interested in it.
- We've
not yet added in the running of the SUnit tests as part of this. Right
now we run this sort of testing prior to versioning the config map for
release. We'll be looking at adding a build job stage to run the tests
in the near future. This first 'cut'
Feel free to post questions about this solution and I'll try to help, but if you have improvements, I'd be most interested.