New Wiki URL Requirement for Plugins

Let's say you're browsing the 'Available' tab in the Jenkins plugin manager for interesting-looking plugins. How do you learn more about them, preferably without installing them on your production instance? You click the plugin's name, which usually links to the plugin's wiki page, of course!

Unfortunately, it's possible for plugins to be published without a wiki page, or any other documentation aside from what's provided in the plugin itself. This is really unfortunate, as users rely on wiki pages and similar documentation to learn more about a plugin before installing or upgrading it, like its features, limitations, or recent changes. Additionally, plugin wiki pages have a special section at the top that provides an automatically generated technical overview of the plugin, such as dependencies to other plugins, the minimum compatible Jenkins version, a list of developers, and links to the source code repository and issue tracker component. Everyone learning about or using a plugin benefits from a plugin wiki page and luckily, almost all plugins have one!

To ensure that every plugin has at least a basic wiki page with some documentation, we decided to only publish plugins in the Jenkins update center that have and link to a wiki page.

Google Apps SSO no longer supported in Jenkins OpenID plugin

This is a guest post from Owen Mehegan (aka autojack)

In 2014 Google announced that they will be shutting down their OpenID 2.0 authentication endpoint and replacing it with Google+ Sign-in, a library built on top of OpenID Connect. The old Google endpoint will shut down on April 20th, 2015! Accordingly, if you are using the Jenkins OpenID plugin to authenticate users with the ‘Google Apps SSO’ feature (typically when Google hosts your personal or corporate email), you need to upgrade. Ryan Campbell took the initiative to develop the new Google Login plugin which implements the Google+ Sign-in functionality. This is the recommended solution going forward. Follow the steps here to configure it for your site. Note that you DON’T need to have a Google+ social network account/profile.

Office Hours tomorrow: workflow security model & plugin compatibility

In tomorrow's Jenkins office hours, Jesse Glick will talk about two topics in the workflow plugin that he has been asked about:

  • Security model: script security, permissions
  • Plugin compatibility: SimpleBuildStep and friends, custom steps, etc.

The session should be interesting to anyone using workflow or thinking about using workflow. Jesse is one of the top contributors in the community, so it'd be definitely worth your time!

Workflow plugin is 1.0

Jenkins started with a notion of jobs and builds at heart. One script is one job, and as you repeatedly execute jobs, it creates builds as records. As the use case of Jenkins gets more sophisticated, people started combining jobs to orchestrate ever more complex activities.

A number of plugins have been developed to enable all sorts of different ways to compose jobs, and many are used quite successfully in production. But this resulted in a certain degree of complexity for users to figure out how to assemble these plugins.

So we felt the need to develop a single unified solution that subsumes all these different ways to orchestrate activities that may span across multiple build slaves, code repositories, etc. Various inputs from users as well as other plugin developers played a key role.

The result of this is the workflow plugin, which is what a number of us, including Jesse Glick an myself, are focused on in the past few months.

The plugin approaches the problem by defining a DSL for you to describe an execution of a job. Various convenient primitives are available, such as executing shell scripts, checking out the source code, obtaining an executor or a build workspace, etc.

Gradle-fy your Jenkins Plugin Project

(This is a guest post from Daniel Spilker)

Jenkins supports building plugins using Gradle for a while now. Last week a new version of the Gradle JPI plugin has been released to iron out some issues.

The Gradle JPI plugin enables a 100% groovy plugin development environment with Groovy as primary programming language, Spock for writing tests and Gradle as build system. Have a look at the Job DSL plugin for an example.

An existing Maven build can be converted to Gradle by using the build.gradle template from the Gradle JPI plugin's README.