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!

Jenkins: Change Workspaces and Build Directory Locations

Have you ever wanted to change the location of the workspace directory of a Jenkins job? Not enough space on your hard drive or your hard drive is too slow? Whatever the reason might have been for your wish, there is a simple solution. Every job in Jenkins has a well “hidden”, I mean really not so obvious, setting to modify the Workspace root location of the job. To change this location, you need to configure your job and click on the Advanced… button in the “Advanced Project Options” section.

Advanced Project Options

Once you opened the settings, you will find some more configuration options for your job. Look for the “Use custom workspace” option on the right hand side and check the box.

Specify custom workspace for job

Here is some information that you should consider reading, prior to change the workspace.

Information about custom workspace

Important: The next build will use the new location, but you have to manually relocate all the existing content from the previous location.

Globally Changing the workspace location for all Jobs

In order of changing the workspace for a single job, there is another option in the Jenkins system settings that allows for changing the workspace for every job.
Navigate to Jenkins->Manage Jenkins->Configure System and click on the Advanced Button on the right hand side.

Specify custom workspace and builds directory location

Voilà! This opens up the following options section

Custom workspace and builds directory location

 
Now you can change your workspace and build directory to any other location on your machine. Jenkins provides 3 predefined variables that can be used to specify the new location:

• ${JENKINS_HOME} — Jenkins home directory
• ${ITEM_ROOTDIR} — Root directory of a job for which the workspace is allocated
• ${ITEM_FULLNAME} — ‘/’-separated job name, like “foo/bar”

The default value for the “Workspace Root Directory” is ${ITEM_ROOTDIR}/workspace and for the “Build Record Root Directory” it’s ${ITEM_ROOTDIR}/builds.

Some Notes

Please be aware, that if you change your workspace to a different location, the contents of the “old” workspace directory are not copied over to the new workspace.
Doing this on OSX could require to change the owner of the newly created workspace. So, if you encounter permission issues during your next build, then have a look at the new location.

Upcoming Jenkins OSX installer changes

I was too busy with other things that prevented me from working on the Jenkins OSX installer recently. Since there are some reported issues with the installer, I'm going to address them in the next couple of days. First of all I'm going to provide a solution for the "data loss" situation that happened several times. This "data loss" situation I'm referring to, is the deletion of a modified jenkins preference file. It's never funny to loose data, even if it's preference data and there were changes specific to your machine.
The other issue is to move from a daemon user for the jenkins execution to a 'real' user. The issue with the daemon user is best described here. I already started to work on this feature and I'm currently testing the feature. Currently I don't have a good solution for migrating from daemon to real jenkins user. This is something I have to find a solution for.

Kohsuke Kawaguchi provided some good documentation for the usage of the Jenkins OSX installer. The document helps to find the available configuration settings, how to display and modify the configuration settings and how to start/stop the jenkins process manually.

So, stay tuned for the upcoming, live easing changes.
Thanks

Notable changes in Jenkins OS X installer 1.427

Okay, nearly every every week there is a new version of the installer available. With every Jenkins release you will also find a new installer for OS X. But that's nothing new. With release 1.427 it's time to tell a little bit about the recent changes in the installer. What else has been changed in the latest Jenkins release can be found here. The installer can be downloaded from here.

What's new in this release?

There were a lot of changes in the recent versions, but I'm going to mention them here too (since they have never been mentioned anywhere else)

• Installation as launch daemon instead of launch agent. If you don't know the difference, here is a good explanation.
• By default Jenkins will be installed as launch daemon, but the user can choose to not install it as launch daemon. In this case only the jenkins.war get's installed. Please start jenkins on your own.
• There is a preference file available to easily tweak the Jenkins program arguments like JENKINS_HOME, prefix, httpPort, etc.
• Documentation with instructions on how to change the arguments by modifying the preference file. The documentation will be installed and is available from /Library/Documentation/Jenkins or you can have sneak peak here.

When it comes to the installation process you will find something like this. More options than ever before. ;-)

Kudos to Sami Tikka for adding the recent improvements.

What's next?

There is currently one big improvements "work in progress": the PrefPane! This will allow you to easily modify the Jenkins settings, start and stop Jenkins, open the logfile, etc.

There is no planned release date for it, but I think it will be available before Christmas 2011.

You have ideas for improvement?

Let us know. We are happy to resolve issues that could ease your life dealing with Jenkins on OS X. The easiest way is to create a new ticket here. If you want to contribute some code, you can even do this by forking the repo on github and start working on it.

List all jenkins jobs with a perforce scm configuration

Here is an instruction on how to execute this groovy script on your jenkins instance to display all jobs that use perforce as SCM provider. This was one of the first scripts I wrote to get an idea about the jenkins CLI and how to execute custom scripts. This script can be used to examine your perforce configurations used for your jobs. In my case it was the foundation to change all passwords for certain perforce user.

Prerequisites
You need to have a java installation on your machine and java must be available on your PATH. groovy itself is not required to execute the scripts.
I assume that you have Jenkins running on your machine, so that I refer to localhost to access the Jenkins instance.

1. If you already have a copy of jenkins-cli.jar on your machine, then skip to step 2. Otherwise open a browser and navigate to this URL http://localhost:8080/cli. Follow the instructions and download the jenkins-cli.jar to a known directory
2. Open a terminal or command window and change into the directory where your jenkins-cli.jar is located
3. Type java -jar jenkins-cli.jar -s http://localhost:8080 help. This will output a list of all available commands that this jenkins instance provides.
4. Okay, now go ahead and save this snippet as listAllProjectsWithPerforceSCM.groovy to the same directory where you previously downloaded the jenkins-cli.jar
   
5. Now enter the following on the command line:
   java -jar jenkins-cli.jar -s http://localhost:8080 groovy listAllProjectsWithPerforceSCM.groovy

This will show you something similar to this output:

Job 'Test' uses the following perforce configuration
------------------------------------------------------------------------
P4Port: localhost:1666
P4Client: testbuilder
P4User: testbuilder
P4Password: 0f0kqlwaDeXrEj0PA0z/+IXZM1f8G8QsgBlUgnUv8bbR2bzXLfa3AlrK8xqw==

That's it. There is nothing complicated about this script, but it shows some of the capabilities to automate certain tasks. Take the script as example to play around with it and explore new ways to interact with jenkins.

Thanks for reading this post.

Jenkins OSX installer

Two weeks ago, I started to work on a simple OSX installer for Jenkins. Last week my work was accepted by Kohsuke and submitted to the repository. Now you can find the installer for the lastest Jenkins release here.

What does the installer do?

• copies the jenkins.war to /Applications/Jenkins
• create a simple LaunchAgent property file (org.jenkins-ci.plist) and add Jenkins as a service
  with a specific JENKINS_HOME location in /Users/Shared/
• start the new Jenkins service after the installation finished

That's it basically.

You can find the installer project on github.

What I did last Thursday: Attending the "Continuous Integration Summit" at LinkedIn HQ

Last week I went to down Mountain View to attend the Continuous Integration Summit. The Event was hosted by LinkedIn in their HQ. I think there were about 100 attendees for this event and the demos from LinkedIn employees about their build system was very interesting. jfrog showed some interesting features for a tighter integration between jenkins und artifactory (for build artifact publishing). Kohsuke Kawaguchi (Jenkins) presented the current state of the Jenkins project and what has changed since the fork from hudson happened. Hans Dockter demoed gradle and how it helps to simplify the build process. All together an event that was worth the time spent. I'm looking forward to the next Summit and a much greater audience.

 

See the full gallery on Posterous

Meetup with Jenkins Developers and Users Meetup Group

I'm going to a Meetup with Jenkins Developers and Users Meetup Group http://meetu.ps/P013