Jenkins: OSX installer now supports the creation of it's own jenkins user

Okay, this doesn't sound like big thing, but there were some valid complaints from users that used jenkins to run their iOS and maven builds. Some of them had trouble with ssh. See https://ljnelson.posterous.com/getting-jenkins-running-on-a-mac and http://colonelpanic.net/2011/06/jenkins-on-mac-os-x-git-w-ssh-public-key.

Since jenkins version 1.449, the OSX installer provides an option to run the jenkins service no longer as daemon user. The installer is able to create a new jenkins user with it's own home directory (maven and ssh, here we come!). It should be easier to grant the jenkins user access to the keychain to allow codesigning of iOS deliverables.

Some facts about the new jenkins user:

• uid will be determined automatically to avoid any collisions with existing users
• guid of jenkins group is determined automatically to avoid collisions with existing groups
• home directory of the jenkins user will be /Users/Shared/Jenkins

Installer options

How to get rid of the jenkins installation?

I heard people talking about issues with the installer updating an existing installation (how can this be?). Some of them asked for way to get rid of the installed files. Since OSX doesn't have a mechanism to un-install files, there are only the options to remove the files manually or use some 3rd party tool (TrashMe) to get rid of the files. Since these tools use some heuristic methods to determine the files to remove, I created a simple shell script to remove all files installed by the installer. The script can be found here.
Warning: I used the script for testing purpose when experimenting with the installer. The are no error checks and it's far from being perfect. So, please use at your own risk!

ConfigSluper, ConfigObject and some stupid bugs

In my last project I wrote some scripts to handle the automatic integration of libraries from different Version Control Systems into our source code repository.
I wrote a script to generate an XML file, that served as input for an existing perl script.

To generate the XML file I used a groovy script which described the dependent components and the revision as well as the platform dependent location in the VCS (which is omitted here).



Processing this file is a pretty straightforward task.



The reason why I'm writing this up, is to tell that I spent a good amount of time, figuring out if there is a bug in the underlying ConfigObject. The ConfigObject is created by ConfigSluper().parse(...) and represents the data in-memory. Since ConfigObject inherits from LinkedHashMap, one can assume (and I really did!), that the semantics are like using a HashMap. But I was wrong! There happens some _magic_, when you do the following:



In my script there was a piece of code that relied on the sub-node count of the Component node. At a certain point, I was really convinced that I found a bug. But that would have been too obvious IMHO, that this kind of misbehavior had slipped through all testcases.
To make a long story short. I did some investigation and found the reason in the implementation of the ConfigObject


You can find the secret (if you will) in line 8. If you access a key in the ConfigObject that doesn't exist, then there will be an empty one created on the fly. This is not really bad, as long as you don't rely on the amount of nodes before and after querying the ConfigObject.