Submitted by hinman on Fri, 2015-07-24 12:37
Slides and video from JUC U.S. East are now available online!
If you attended the conference, THANK YOU, and I'm sure you had fun, learned a lot and met many people from the Jenkins community. Now you can revisit your favorite talks or "attend" the ones that you missed.
If you were unable to attend JUC U.S. East, you now have the slides and video so you can "attend" anyways! If you like what you see and would like to attend a JUC this year, there is ONE date left in the 2015 Jenkins User Conference World Tour: JUC U.S. West is September 2-3 in Santa Clara, CA. Register here.
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:
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.