Using Jenkins build parameters in SCM fields

At my current client, I’m doing some prototype work and controlling my CI process with Jenkins. I’ve been using Jenkins/Hudson for years, but usually with a group of folks, and not while flying solo. After installing the requisite Chuck Norris plugin (5 projects in a row!), and setting up all of the typical jobs, I thought it might be handy to have a job that would prepare a ‘release’- a checkout and build of a specific tag from CVS, where the tag is provided via a parameter given to the job via the parameterized build style that Jenkins provides.

So, I set up a parameterized build and created a string parameter called ‘TAG’. I thought I’d just drop ‘${TAG}’ into the ‘branch/tag’ field in the ‘Branch’ field in the Source Code Management section of my job config. Shortly thereafter, I ran into my first unresolved Jenkins issue – JENKINS-3230. Build parameters aren’t available in the Source Code Management section of the job config. The ticket doesn’t appear to have moved in a while, and being in a jam, I thought I’d work around first, then revisit contributing to a fix or finding a more permanent solution later.

Fortunately, the solution is simple. Just remove the calls from the SCM section of the job config (change that section to ‘None’) and replace with equivalent (in my case) instances of ‘Execute Windows batch command’.

For me, the command ended up looking like this:

cvs -Q -z3 -d :pserver:me@myserver:2402/cvs/repositories/myrepository co -P -r %TAG%

If it’s a maven build, and you’re executing top-level POMs, you’ll also have to change subsequent ‘Invoke top-level Maven targets’ sections in your config to specify the parent project name in the POM field (, instead of just using the default (pom.xml).

It’s just a bit more maintenance (and kind of a hassle to have to remember all of the CVS parameters), but it works!

…on the virtues of numbers divisible by many other numbers (especially 960)

Many months ago, I came across an article about the 960 grid system. I excitedly read more about it thinking that it could help me modernize my page design skills relatively easy as well as provide a quick way to get prototype layouts up. I’m finally getting a chance to use it now while working on a site for a relative’s small business in my spare time. While it’s great to write the comprehensive, go-to post for quick reference on an emerging tool or technology, for the 960 grid system, it’s already been done.

I’ll link to it instead. From Six Revisions:

The 960 Grid System Made Easy

Between this article and the examples that come with the download on – which includes templates in a whole slew of formats – you design-challenged back-end developers should be in luck. I certainly was.

SpringOne2GX, Day 3 Recap

Two great demos in the morning regarding Gradle, by it’s author, Hans Docktor. Gradle is something I’d heard about frequently, but never bothered to look into thinking that I didn’t need to learn another way to build until it was necessary. Combining the declarative nature of a DSL with the scripting capabilities of Groovy, Gradle looks to be a “next generation” build tool. Familiar constructs exist – job, task, etc – but each of those constructs has properties that can be inspected, and the DSL itself can be easily extended to meet an organization’s need. Since the Ant jars are packed with Gradle, it looks like Gradle should have easier inroads into the enterprise than other new build technologies. Any task or all of the build can be written using Gradle, which would allow for a migration approach as opposed to a conversion. The demos themselves were smooth and engaging with no technical hiccups. Really good stuff.

The last talk of the conference was a demo of Daisy CMS Grails. Like a few other talks/demos, I learned more about the subject itself (CMSs) rather than the technology that was the subject of the talk.

In all, a good conference. The quality of content in the talks varied greatly. Some were demos, some were presentations, and others seemed like they were thrown together at the last minute. The good content was great, and the not-so-good content, well, was not-so-good. Although I’m sure the pub crawl was fun, I think the conference could have fit into two days had the lower quality material been removed. I came away with a few exciting things to look into and a new appreciation for the Spring/Groovy community.