Recent Blog Posts

+ + + Today on IRC, I was asked how someone new to the project can get started working on Jenkins, when s/he has no particular preference or pet-peeve. + + + This is a good question for which the project should have a canned answer ready, so here is one approach — adopt a plugin! + + + Often, a Jenkins plugin gets developed by someone to scratch his own itch. That person shares the plugin with the community, and since it does everything he needs, he moves on to work on something else. Then another person starts using that plugin, comes up with an idea for improvement, implements that, and then moves on. Given that we have more than 900 plugins today, there are a plenty of plugins that are currently co-maintained by the community, which could really use a focused loving caregiver. + + + So why don't you adopt a plugin? You can pick up one of those plugins and act as a maintainer. You'll hear appreciation from people who are using that plugin, and most plugins are small and simple enough even for people new to Jenkins. Above all, working on plugins don't require much communication with existing developers and implicit processes, which is often difficult for new people to find out. + + + Here's how you can find a plugin to adopt. You can look at https://wiki.jenkins.io/display/JENKINS/Pending+Pull+Requests[repositories that have most pending pull requests]. Plugins with lots of pull requests likely could use some help, so check if anyone is actively working on it and talk to him, or if you don't see much activities from a single person, just go ahead and adopt the plugin. + + + https://stats.jenkins-ci.org/jenkins-stats/svg/svgs.html[Usage statistics] has `+top-plugins500.svg+` (this is for https://stats.jenkins-ci.org/jenkins-stats/svg/201404-top-plugins500.svg[the last month]). Open that in Firefox, which lets you zoom in. Scroll all the way to the right, and you see popular plugins. Compare that with https://github.com/jenkinsci/[our GitHub repositories], and you can find popular plugins that aren't getting enough love. + + + https://issues.jenkins.io/browse/JENKINS#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel[Issue tracker] is also a good place to look for a plugin in need of help. Every plugin has a separate component, so look at bugs and RFEs filed against those, especially with lots of votes. Fix a bug is great, but even just helping with the triage process would be highly appreciated. + + + Try adopting a plugin for a while, and when you get the hang of it, let https://groups.google.com/forum/#!forum/jenkinsci-dev[the dev list know]. Update `+pom.xml+` to have your name listed as a maintainer. Come https://jenkins-ci.org/content/chat[join IRC]. That way, we know who you are and how to reach you. + + + See, it's really not that hard. And there's something really satisfying in making things a little better and seeing happy users. Anyway, looking forward to working with you!

At the first Bay Area Hackathon in mid-2009, the topic du jour was " pre-tested commits." As potential implementations of the concept were discussed over burgers from Brickhouse in downtown San Francisco, we realized as a group a few things: first, those burgers were delicious, but more importantly: pre-testing commits is very-SCM dependent and involves a lot of moving parts. One of the positive changes that came out shortly after the meet up was the support for "Concurrent Builds", allowing a job to be executed concurrently on different agents, a precursor to pre-tested commit support. Fervor for the pre-tested commit feature lowered as time went on, the feature being too dependent on the SCM itself was generally accepted as the reasoning behind the feature languishing. Chances are the feature is in fact too large for Hudson to support alone. It requires Hudson, the SCM and likely a third tool to work in concert together to perform such a feat. With Git, and the phenomenal code review tool Gerrit, and the Gerrit plugin by intrepid plugin developer, Jyrki Puttonen, pre-tested commits with Hudson, Git and Gerrit are possible. For Git users more familiar with the distributed Git workflows, working with Gerrit should seem familiar. Gerrit has JGit, a Java implementation of Git embedded within it, along with an sshd stack, meaning Gerrit can masquerade as a "regular" Git remote repository. Developers can push and pull to the repository just as they can with any other Git repository (provided they have permissions of course). I won’t delve too much into using Gerrit specifically here, but the pre-tested workflow with Gerrit and Hudson would look something like this: Dev creates a topic branch to work on a change Code is written (and hopefully tested) and committed locally Dev pushes commit(s) to Gerrit Hudson job (set to Poll SCM) picks up the patch, runs the job and marks it as "+1 Verified" or "-1 Fails" If the job fails or is unstable, the change should be reworked or corrected (typically with git-rebase(1)) If Hudson says the change is good to go, it can be cherry-picked or pulled directly from Gerrit. For example: image:https://web.archive.org/web/*/https://agentdero.cachefly.net/continuousblog/gerrit_patch.png To learn more about Gerrit, check out the project page on Google Code; information on the Gerrit plugin can be found on the wiki.

After Hudson got some major publicity at PyCon Atlanta 2010 I haven’t been as quick as I would have liked with Python-related posts and tutorials. I use Hudson to build and test a number of pure Python modules and C extensions across numerous Python versions (covering 2.4 - 3.1). For most beginners, or those simply looking to get started with Python on Hudson, starting with my job configurations is too much at once, so instead I wanted to start at the "beginning" so to speak. The trouble with getting people started with Hudson, given how simple and visual it is to use, is that articles with sample configurations are not particularly useful; a screencast however is a good medium for visually walking somebody through Hudson. The screencast below ( also on YouTube) is the first in a series of screencasts I’ll be doing, not only for Python on Hudson, but for Hudson overall. It is just over four minutes long, and covers setting up a simple continuous integration job for the Eventlet library (which is hosted on Bitbucket)

A few weeks ago our fearless leader Kohsuke Kawaguchi joined the San Francisco Java Users Group to talk about continuous integration with Hudson. Thanks to Marakana for organizing the meetup, and Aleksandar Gargenta for posting the video and slides, embedded below. Learn About Continuous Integration With Hudson Directly From the Source

In this post I’ll show a very basic tips on how to compile an Android project using Hudson. Specifically how I use Hudson to create release versions of my apps. Debug vs Release I’m assuming that you are using Eclipse with the ADT plugin. During development you can test your app on the emulator or a device and resources like R.java and aidl files are compiled for you automatically by the plugin. When it’s time to release your app, you’ll need to go through some steps: You must sign your app using a certificate You must update your AndroidManifest.xml to remove the android:debuggable attribute Replace your Google Maps API debug key with the one belonging to your release certificate (if you are using a MapView) Generate an apk package for the release and test it on a device or emulator It would be nice to automate a few of these steps, and this is where Hudson comes in. Automated builds: Ant For automated builds the Android SDK uses Apache Ant, which Hudson has great support for. To generate a template build.xml you can use the android tool from the SDK using the following command: android create project -n template -t android-7 -p template -k dummy.pkg -a Dummy The target is specified as "android-7" meaning that we are building for Android 2.1. For apps that use MapView we would use "Google Inc.:Google APIs:7". It is a good idea to always target the latest SDK. From this template project we’ll grab the build.properties and the build.xml and copy those to the Android project that we want to build. Edit build.xml and set the project name to your Android project name. The local.properties file contains the path to the SDK root and shouldn’t be checked in to version control. For our use we’ll set the properties that are in that file on the Hudson job configuration page. Running the build in Hudson This part is easy: create a new freestyle job and let it be build with ant. The targets that we want to execute are clean release. Release will compile, package and sign your apk. Now to get this working right, some custom properties should be set (use the Advanced button). sdk.dir=/Users/hugo/Code/android-sdk-mac target=Google Inc.:Google APIs:7 key.store=certs/rd-release.keystore key.alias=rainydays key.store.password=thisisnotmypassword key.alias.password=thisisnotmypassword The sdk.dir should point to the Android SDK root on your Hudson node. In my case I’m running Hudson locally on my machine. The target property refers to the SDK we want to use as mentioned earlier. The key. properties are related to signing of the apk. My strategy is to have a separate key store and private key for each application that I develop. I also check that keystore in to SVN. I also archive the -release.apk artifact so that I can download the latest release apk directly from Hudson. After completing these steps, you should be able to build your Android app with Hudson. Updating the AndroidManifest for release …​But we’re not done yet :) Remember what I said about updating the AndroidManifest.xml? For that we need to edit the build.xml, which by default contains nothing more then a tag to pull in the Android SDK ant target definitions. For my Rainy Days application, I adjusted build.xml like this: ... Removing debug attribute from AndroidManifest.xml Setting release maps key What the above snippet does is removing the android:debuggable attribute from the AndroidManifest.xml and replacing the maps API key in res/layout/maplayout.xml with the correct key for release. The -package-resources target is pulled in from the Android android_rules.xml file. Now when Hudson builds my app I get a ready to release apk that I can install on my device or emulator, which is pretty nice. There is are some issues with this approach however. As you might have noticed: Replacements are done in the workspace, we are not really building exactly what’s in svn Each new build should start out fresh for that reason, for example by using the svn revert option. Additionally I can not yet tag the release version with the updated files, because the subversion tagging plugin doesn’t support this by design. This could be worked around by adding svn statements in the build.xml however. For now I don’t really mind as I make minor changes to the resource files, but I’ll be looking at improving this situation. Things to add: unit testing, coverage…​ One thing that I’d really like to add is unit testing. This is a little bit more complicated though, since unit tests require a running emulator and a running emulator requires a gui. The Hudson Xvnc plugin could be very helpful here. The Android build scripts for test projects already include EMMA output, it shouldn’t be to hard to use the Hudson plugin for that. When Hudson is running on a local machine, the Batch task plugin can automate installing the apk on a device to automate things further. Summary Building Android applications with Hudson is not that hard, since the builds are based on Ant. By hooking in to the standard Android build targets it’s easy to update files like AndroidManifest.xml which in turn makes sure the release process is controlled and predictable. Android unit tests depend on the emulator which is a little bit more challenging to set up, but Hudson already has some plugins available to make this easier. Editor’s Note: Hugo Visser is the developer of Rainy Days and Engine Watch for Android. You can follow him on Twitter and on his blog.

We all know that keeping important files in version control is critical, as it ensures problematic changes can be reverted and can serve as a backup mechanism as well. Code and resources are often kept in version control, but it can be easy to forget your continuous integration (CI) server itself! If a disk were to die or fall victim to a misplaced rm -rf, you could lose all the history and configuration associated with the jobs your CI server manages. It’s pretty simple to create a repository, but it isn’t obvious which parts of your $HUDSON_HOME you’ll want to backup. You’ll also want to have some automation so new projects get added to the repository, and deleted ones get removed. Luckily we have a great tool to handle this: Hudson! We have a Hudson job which runs nightly, performs the appropriate SVN commands, and checks in. The high-level overview of this job is basically: Add any new jobs, users, plugin configurations, et cetera: svn add -q --parents.xml jobs/ /config.xml users/ /config.xml userContent/ Remove anything from SVN that no longer exists (such as a deleted job): svn status | grep '!' | awk '{print $2;}' | xargs -r svn rm Check it in! svn ci --non-interactive --username=mrhudson -m "automated commit of Hudson configuration" You’ll want to make sure to use the --non-interactive option for any automated svn operations, as this ensures Subversion won’t hang asking a question but instead fail immediately. You may also need to provide your password with the --password option. To make such a Hudson job, create a new job, tie it to the controller (since this is where the configuration files are), set it to build periodically (we use “@midnight”), and add an “Execute shell” build step. Here’s the full script we use, to put into the build step: # Change into your HUDSON_HOME. cd /opt/hudson # Add any new conf files, jobs, users, and content. svn add -q --parents *.xml jobs/*/config.xml users/*/config.xml userContent/* # Ignore things in the root we don't care about. echo -e "warnlogn*.logn*.tmpn*.oldn*.bakn*.jarn*.json" > myignores svn propset svn:ignore -F myignores . && rm myignores # Ignore things in jobs/* we don't care about. echo -e "buildsnlast*nnext*n*.txtn*.lognworkspace*ncoberturanjavadocnhtmlreportsnncoverndoclinks" > myignores svn propset svn:ignore -F myignores jobs/* && rm myignores # Remove anything from SVN that no longer exists in Hudson. svn status | grep '!' | awk '{print $2;}' | xargs -r svn rm # And finally, check in of course, showing status before and after for logging. svn st && svn ci --non-interactive --username=mrhudson -m "automated commit of Hudson configuration" && svn st You’ll notice this does some extra things like set the svn:ignores property to provide a relatively clean svn st which it shows before and after the commit for logging purposes. One thing this job doesn’t do is put the build results of your jobs in version control. Because historical build logs and artifacts will never change and are also potentially large, a periodic (daily or weekly) cp or rsync of the jobs directory will still give you restorability while keeping your repository lean. Now you can sleep well at night knowing that your CI server is safe and sound. If you are doing a similar thing with Hudson or another CI system, let us know about your solution! Editor’s Note: Mike Rooney is a Software Engineer at Genius.com, provider of real-time marketing automation software connecting marketing and sales. You can read more posts from Mike and other Geniuses at eng.genius.com