I recently switched our entire build system over to using a Jenkins build server. It’s been running for a couple weeks now and I keep expanding the jobs I have it doing, and all in all I’m very happy with how it’s going. It’s certainly saved me a load of time and the fact we now are getting automated nightly builds of all of our installers is extremely valuable to us and our customers.
Once of the challenges in getting things working was getting the build of the Linux installer for Solution Engine automated. The Jenkins Server is a Windows Server and Solution Engine in built using Mono, but the actual deployment package is a tarball. Generating tarballs on a Windows platform really isn’t well documented or outlined anywhere that I could find, but I was able piece the process together from some help files, man pages and a lot of iterations.
In the end, the build portion of the job is done through four separate “Execute Windows Batch Command” steps.
Step 1: Compile the Solution
This one was pretty straightforward. You simply use the xbuild.exe application that ships with Mono and point it at your Visual Studio/Xamarin Solution File:
"C:Program Files (x86)Mono-3.2.3libmono4.5xbuild.exe" /p:Configuration=Debug SolutionEngine.Mono.sln
Step 2: Copy the results
xbuild puts the files into the output structure I want (that’s how the Visual Studio solution is architected) but it also generates a lot of cruft. I use robocopy, which is already part of Server, to copy all of my files except files with a *.pdb or *.mdb extension to a temporary output location:
robocopy PublishSolutionEngineDebugMono Installersoutput /s /xf *.pdb *.mdb
Step 3: Put the results into a tarball
Next I use 7-zip to build the tarball. This part was surprisingly confusing. 7-zip has some documentation, but it’s far from clear, and I even found a page that had “command line examples” but I’m not sure that it really gave me any more clarity. In the end I just did lots and lots of iterations on the build, checking the output every time to see what happened. In the end, this is the command I ended up with:
"C:Program Files (x86)7-Zip7z.exe" a -ttar SolutionEngine.tar "%WORKSPACE%Installersoutput*.*" -mmt -r
This breaks down as follows:
- The ‘a’ flag means I’m creating (as opposed to extracting from) an archive
- -ttar is a switch meaning “type tar” – I’m using a tar container (as opposed to say a zip, iso or whatever)
- SolutionEngine.tar is the output file. It ends up in the working folder where I’m running command.
- The next section is the “source”. %WORKSPACE% is an environment variable Jenkins sets and the rest of the path you can see is the destination from Step 2 above. *.* means I want everything found at the source location in the tar.
- -mmt means “use multi-threading when compressing” which I think ends up using multiple cores if available. I didn’t compare times with and without, so I don’t know how much it helps and it’s probably negligible – my end tar is only about 9MB. Having the switch doesn’t cause problems, so I’m leaving it in.
- The -r flag means “recurse the source.” My source folder has several layers of subdirectories and I want them all in the tarball, maintaining the folder structure. This flag achieves that.
Step 4: Compress the tarball
For those unaware, a “tar.gz” file is a double operation – package, then compress the package. Step 3 built the package, but to be friendly to both my upload process and our customers who have to download it, I also compress the file. To compress the tarball with gzip compression I again use 7-zip.
"C:Program Files (x86)7-Zip7z.exe" a -tgzip SolutionEngine.tar.gz "%WORKSPACE%SolutionEngine.tar"
This one is simpler than Step 3 and breaks down as follows:
- The ‘a’ flag, again, means I’m creating an archive
- -tgzip is a switch meaning “compress using type gzip”
- SolutionEngine.tar.gz is the output file. Again, it ends up in the working folder where I’m running command.
- The next section is the “source” file, which was the tar file output by Step 3 above.