Submitted by hinman on Fri, 2015-10-02 10:06
Over 2,000 members of the Docker community attended Docker Hack Day events around the world. One of the forty-two Docker Hacks has some familiar names attached...
Nicolas De Loof and Yoann Dubreuil from Docker Rennes, who are also active in our community, waved the Jenkins flag in this event and produced Jenkins docker slaves plugin.
This plugin lets you run builds inside containers, and in that sense it's similar to the Docker plugin and the Docker custom build environment plugin. But internally it uses a quite interesting approach.
Most Jenkins masters with a distributed build configuration will leverage nodes that run a
slave.jar to start a slave agent. Regardless of whether the
slave.jar is launched through a Java Web Start or SSH launcher, the jar will be copied from
http://yourserver:port/jnlpJars/slave.jar to the build node. Keeping this jar up to date ensures that it picks up the newest features in a more recent release, such as the self-restart feature to keep slave JVMs “clean” and to automatically reconnect to their master. Additionally, newer versions of this component may fix bugs or implement newer protocol versions with various improvements.
What is the Version Column Plugin?
Launch methods designed to pull the latest
slave.jar are not always reliable and some launch methods don’t even try to update the
Nicolas De Loof will host an office hour next Wednesday 11 AM PDT on integrating Kubernetes with Jenkins. Kubernetes is an open-source project by Google that provides a platform for managing Docker containers as a cluster.
During this session, Nicolas will introduce Kubernetes, explain how it can benefit Jenkins and demonstrate the Kubernetes Plugin.
Then he will discuss the design of the Kubernetes plugin and plans he has for future improvements.
Participate in the Hangout on Air or watch live on YouTube.
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.