Submitted by kohsuke on Mon, 2013-09-23 08:00
Lately there has been several cases where we wanted to deliver beta versions of the new plugins to interested users.
To simplify this, we have created a new "experimental" update center, where alpha and beta releases of plugins will be available. Users who are interested in downloading them can go to "Plugin Manager", then to the "advanced" tab, and type in http://updates.jenkins-ci.org/experimental/update-center.json in the update center URL field.
When you are looking for the "available" tab, plugins that are experimental are marked accordingly to help you decide which ones to install. Once you install the beta plugins that you wanted, you can switch back to the default http://updates.jenkins-ci.org/update-center.json update center.
If you are developing plugins and you want to distribute experimental plugins, all you have to do is to put "alpha" or "beta" in the version number of pom.xml. The backend infrastructure takes care of the rest.
This is a guest post by Mike Rowan, VP R&D at SendGrid.
Q: Tell us a bit about what your service and plugin do. Who is it for? What are the highlights of your plugin?
A: Loader.io is a simple-to-use cloud-based load testing service. The service is designed for developers and people who need to ensure applications are performing as they should. It allows developers to perform large-scale load tests on demand, which lets them understand the scalability and performance of their applications. We realize Jenkins is the preferred build service for a lot of our users, and we know providing a way for them to implement, measure and improve application performance during the continuous build cycle is important. So we wrote a Jenkins plugin that allows load testing to be brought into the continuous build and deployment process with ease.
Q: Did you have to convince your boss/lawyers to open-source your plugin? What was the pitch?
This Wednesday's Jenkins office hours is all about the Git plugin refactoring that's going on.
Git plugin is one of the most popular plugins out there, and it's been around for quite some time. Combine that with the fact that there are so many different ways to use Git, it was inevitable that Git plugin became quite a capable but complex plugin over time. It has more than a dozen options and switches, and it was becoming harder to use and harder to maintain.
As early as 2010, some of us have already been saying that we should refactor this plugin, but none of us have managed. The good news is, I finally started tackling this problem last month while I was in London, and I've made a steadily progress since then and I'm ready for a wider review.
So we'll spend this Wednesday going over the changes.
As the usage of Jenkins expands, we started seeing users who run multiple 100s of slaves on one master, and thus it became a lot more important for us to scale well to even larger number of slaves.
While I was looking at the thread dump of a large system, I started noticing that there are a large number of threads lying around pumping InputStream and writing to another OutputStream. On Linux, each thread occupies 2MB just for its stack size, so if we can eliminate some of them, it'd be a good saving.
So this morning, I tackled one source of such waste.
Jenkins has the ability to launch slave on a remote server via SSH for the longest time, and to simplify this, we've been using a pure-Java implementation of SSH client.
To cut the long story short, I was able to eliminate two pump threads per every SSH connection. Furthermore, when it runs on the upcoming Jenkins 1.521, it'll save one more thread per every SSH connection. So if you have 100 slaves connected through SSH, this alone saves up 600MB of memory. That's pretty good for a few hours work!