Development

Critical security advisory in Jenkins core

We've identified and fixed a critical security vulnerabilities in
Jenkins core. This affects all the releases of Jenkins to date (main line releases up to 1.452 and LTS up to 1.424.3.) Please upgrade to the new releases at your earliest convenience, especially if your Jenkins is internet facing.

For more details about the vulnerabilities, affected versions, and so on, please consult the security advisory.

(See our Wiki page about security advisories about how we do these.)

Building Jenkins plugins with Gradle

Until now, Jenkins plugins written in Java or Groovy could only be built with Maven, using the maven-hpi-plugin to generate a proper manifest and archive which Jenkins can consume. But starting now, you can also use Gradle!

See the wiki for information on how you can use Gradle and the new gradle-jpi-plugin to build, test and release your Java or Groovy Jenkins plugin.

Jenkins survey result and what UI improvement would you like?

Jenkins community survey result is in, which shows a number of interesting stats for us developers, such as 82% of people saying their Jenkins is mission critical, or the spread of distributed builds, especially compared to my earlier similar usage analytics.

But just as interesting is the free-form answers to questions like "If there was anything you could you change about Jenkins CI, what would it be?", and while the answer is colorful, there are a few common themes that one can easily spot.

One of them is "nothing!", which made me feel good, but another is "UI improvement." And incidentally, Domi has started a thread in the Jenkins-users list about this exact topic a week ago.

The idea is to brainstorm what kind of concrete improvements people would like to see, then run them through some real user experience designers and decide which ones are good ideas and which one

Community-contributed localizations to be bundled in Jenkins 1.443

In 1.430, we added the translation assistance plugin in the hope of increasing the contribution from the community. It's been 3 months, and I've finally took the opportunity to integrate them into Jenkins.

The result is pretty amazing. Before this, we had 26 languages, with wildly varying degree of completeness, such as French, Japanese, German, etc. This is still pretty good, but this integration added updates to 40 languages, including 17 brand-new languages, pushing the total up to whopping 43 languages. Among the newly added languages are Arabic (sorry, no right-to-left support yet), Esperanto, Hebrew, as well as large amount of Chinese (both simplified and traditional) and Korean.

While working with this, I've also discovered an issue that prevented Jenkins from correctly showing Hebrew, Indonesian, and Yedish localizations. All these changes will be in 1.443. And going forward, I'll be integrating changes more frequently to reduce the delay.

JRuby Branch merged!

Yesterday, Kohsuke announced that the 'jruby' branch of jenkins-core had been merged to master.

This doesn't mean that we're done and that you can go forth and write pure ruby plugins... not by any stretch of the imagination. Instead, what it does mean, is that the Jenkins mainline is much more friendly to runtime analysis of classes with which it is not familiar.

The problem

When analyzing plugin classes, Jenkins uses just about every kind of metadata you can think of to get information about them: Class name, Field names, method names, member modifiers, annotations, you name it. It even uses the containing class relationship for inner classes to match Descriptors with what they describe.

It's all a great example of convention over configuration (CoC). In fact, I've never really seen CoC implemented in a Java project before as successfully as it has been in Jenkins. Plugin authors don't have to duplicate any metadata that Jenkins can figure out for you -- and it's alot! The drawback though, is that extensions depend very heavily on conforming to the structure of a conventional Java class.

The changes in this merge, and in several of the modules on which Jenkins depends, allow more than ever to get this information by asking an object directly rather than querying its private class structure.

The Kicker

Many of theses changes aren't even JRuby specific! While they do enable JRuby integration, They're really just making things more friendly for dynamic languages in general. So, in theory, it should pave the way for others like JavaScript and Python.

Where now?

We're still working on the ruby runtime and tools which will provide as crisp a Ruby development experience as we can. I don't want to proffer an estimate of when those will begin to be useable, but it is important to mark this very important milestone and explain what it does and does not mean.

We need you!

There is still much work to be done to enable a writing Jenkins plugins in Ruby, we are looking for people who know Ruby and feel like pitching in: writing Rake tasks, improving the glue layer, documentation, etc.

If you're interested, most of the action is happening on the jenkinsrb@googlegroups.com mailing list, so join us!