As you may have noticed, our wiki and issue tracker were unavailable from Thursday to Sunday last week. What happened? We host parts of our infrastructure at the Open Source Lab at Oregon State (OSUOSL), including the databases for these two services. So far, there’s no post mortem by OSUOSL (they expect to post one later this week), so we need to piece together what we know. The databases for the wiki and issue tracker became inaccessible around midnight/12 AM Thu/Fri night (all times UTC). Due to the large number and size of databases on that server, pulling from backups, restoring from backup and replaying the binlogs took them quite a while. During that time, we put up a maintenance screen on the wiki (and messed up the one for Jira, so there were connection timeouts instead). The databases were back around 3 AM on Sunday. We disabled the maintenance screens around 6 PM later that day. While this was a rather lengthy outage, it could have been much worse. We lost none of the data, after all. We thank the OSUOSL team for their efforts getting everything back up over the weekend!

There’s only a month left until JUC U.S. West on September 2-3! If you’re still on the fence, check out the recaps of JUC Europe talks recently posted to the CloudBees blog. These should give you an idea about the kinds of talks you can expect at a Jenkins User Conference: How to Optimize Automated Testing with Everyone’s Favorite Butler Configuration as Code - The Job DSL Plugin From DevOps to NoOps If you’re interested in the upcoming Jenkins UI overhaul, make sure to attend Gus and Tom’s talk about it. Don’t want to wait until JUC to learn more about this? Follow the discussion on the developers mailing list and contribute through early testing. This JUC will again have an Ask The Experts booth with several Jenkins experts and developers available there throughout the event. If you want to discuss Workflow with Jesse, or pitch your UI ideas to Gus, this is where you’ll be able to do that.

This is a guest post by Manuel Recena Soto (aka recena). Users of the plug-in know that it has undergone very important changes in the last two years. Unfortunately, some of these changes resulted in regressions for some users that weren’t properly addressed in subsequent releases. Many users were therefore forced to keep using an older release of the plugin to keep their instances running. To fix this difficult situation I’ve decided to dedicate my spare time to improving the plug-in and attempting to restore the stability that an essential plug-in like this requires. In order to do so, me, my colleague Steven Christou and other members of the community have drawn up a plan. In the coming weeks we will be focusing our efforts on: Going through the Jira tickets Checking whether they are duplicated Checking whether they are still relevant Asking for more information from the people who reported them Establishing their priority Reviewing pull requests Investigating bug reports and try to reproduce them Fixing serious bugs Refactoring the plugin to improve its maintainability. We’re planning to publish a new 2.5.x bugfix release once a fortnight. We are not considering the inclusion of new features or improvements. The priority now must be to obtain a stable and reliable plug-in, one that will allow us to take things up again in the future with greater security and peace of mind. Interested in helping? Just send us a message!

Kubernetes is an open-source project by Google that provides a platform for managing Docker containers as a cluster. In their own words: Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. Using the concepts of "labels" and "pods", it groups the containers which make up an application into logical units for easy management and discovery. Kubernetes-related services by Google are the Google Container Engine, a Kubernetes-powered platform for hosting and managing Docker containers, and the Google Container Registry, a private Docker image registry. Several new Jenkins plugins allow you to make use of Kubernetes and these services: The Google Cloud Registry Auth Plugin allows users to authenticate with the Google Cloud Registry so they can push/pull images. This allows you to use the Google Cloud Registry with existing Docker-related plugins, like Docker build step plugin or CloudBees Docker Custom Build Environment Plugin. The Kubernetes Plugin implements a cloud provider for Jenkins, and can create agents based on Docker images on-demand on your Kubernetes cluster or the Google Cloud Platform. Watch Kohsuke demoing Jenkins/Kubernetes integration at OSCON earlier this week. For a more in-depth look at how you can use Kubernetes with Jenkins, check out these posts on the CloudBees blog by Tracy Kennedy: Orchestrating deployments with Jenkins Workflow and Kubernetes On-demand Jenkins agents with Kubernetes and the Google Container Engine Clustering Jenkins with Kubernetes in the Google Container Engine

After several months of inactivity, office hours, the bi-weekly meeting of Jenkins users and developers to learn more about Jenkins, are back. I’ll host the first session next Wednesday at 11 am PDT. This session will be about Stapler, focusing on what Jenkins plugin authors need to know about it, e.g. request routing, form submission handling, or how Jelly/Groovy views work. While this is going to be a developer-focused session, future session topics will also have Jenkins users as target audience. For general information on office hours, and how to join, see the wiki.

This is a guest post by Kirill Merkushev at Yandex. I met him at JUC Europe where he showed me the project he was working on: Juseppe. It looked really interesting, so I asked him to write this guest post. When you write your first custom Jenkins plugin for internal use, it’s easy enough to deploy it on one or maybe two Jenkins instances. You can save it on your local drive and upload the HPI file via the Jenkins Plugin Manager as needed. It’s easy to do this for a few releases. But as your experience grows, the number of plugins and their releases grows as well. The plugins directory on your local drive soon looks like a garbage dump, and it’s difficult to find that most recent version of any plugin. And if you have a lot of Jenkins instances coordinating updates of your plugins may cause a lot of pain. A similar situation is when you contribute a much-needed patch to an existing plugin, but you don’t have the time to wait until your pull request is be merged and a new release is cut. Or you may need to patch a plugin in ways not suitable for distribution, and decide to effectively fork the plugin for use on your Jenkins instances. How are you going to do this? A solution avoiding the problems from these situations is to set up your own update site to serve your private plugin builds. Juseppe allows you to do this quickly and easily. What is Juseppe? Juseppe is an acronym for Jenkins Update Site Embedded for Plugin Publishing Easily. Juseppe can help you set up a Jenkins update site in just a few minutes. Features Generates signed update-center.json and release-history.json Works with HPI files directly (stored in one folder), no need to set up a Maven repository Watches for changes in the plugin folder and regenerates JSON files when changes are detected Serves generated files and plugin files with built-in Jetty web server Can be run in a "generate-only" mode when you want to use a different web server for these files. How can I get Juseppe? It ships as a Docker container, or can be built from source. Visit the GitHub project page to learn more. The complete user guide is available in the GitHub project wiki.

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. To keep the impact to a minimum, we’re implementing this plan in several stages. The first stage went live on June 1: All existing plugins that don’t have a (valid) wiki link got a wiki link assigned by the update center (a so-called 'override'), either to an existing wiki page if there was one, or a generic"This plugin has no documentation" wiki page otherwise. This ensures that no currently existing plugins get dropped from the update center at this point. Of course, new plugins that don’t provide a wiki URL and don’t have an override URL will not show up at all. The second stage will be enabled later this year: We’re planning to remove all the overrides mentioned above. At this point, plugins may get removed from the update center if they still don’t specify a wiki URL. Of course this isn’t our goal, and we’ll try to work with plugin authors to prevent this from happening. So what can you do? Check the current overrides list to see whether the plugins you care about are affected, and if so, see the landing page in the wiki to learn what you can do. If you have any questions about this process not covered by the wiki, ask us on the Jenkins developers mailing list.