JUC SF on October 23, 2014 is shaping up to be bigger and better this year.
Here’s what we have in store for you!Three Tracks
We’ve received a record high of 40 stellar proposals this year. To accommodate the many community proposals, we’ve decide to add a third track to the agenda. JUC SF sessions are now available for you to view. We have speakers from Google, Target, Gap, Cloudera, Ebay, Chicago Drilling Company, and much more. Register now for early bird price. The early bird price is only good until September 21, 2014.Live Stream
Have a beer while learning how to write Jenkins plugin. Steve Christou, Jenkins support engineer will lead this lecture from 3:30pm to 6:00pm. He will teach everything from how to get started, to techniques like writing a new CLI Command, to writing your own builder.Ask the Experts
Meet the Jenkins creator, committers, support engineers, and developers. We have dedicated time slot(s) for our attendees to get 1 on 1 access to our experts. Exact time is TBD. Ask them anything from plugins, configuration, technical support, to bug fixes.
Our current list of experts are:
- Andrew Bayer
- Gareth Bowles
- Steve Christou
- Jesse Glick
- Kohsuke Kawaguchi
- Dean Yu
Want to join our panel of experts? Contact Alyssa Tong email@example.comExhibit Mixer
Sixteen technology sponsors will be showcasing their newest technologies during the exhibition hour from 2:25 – 3:30pm. Grab a beer, visit with sponsors and see how they are using Jenkins.
This is just a taste of what you’ll see at JUC SF. We look forward to seeing you there!!
Jesse and I will walk through the source code of the workflow plugin, highlights key abstractions and extension points, and discuss how they are put together.
If you are interested in developing or retrofitting plugins to work with workflows, I think you'll find this session interesting.
(This is a guest post from Michael Neale)
Recently at the Docker Conference (DockerCon) the Docker Hub was announced.
The hub (which includes their image building and storage service) also provides some "official" images (sometimes they call them repositories - they are really just sets of images).
So after talking with all sorts of people we decided to create an official Jenkins image - which is hosted by the docker hub simply as "jenkins".
So when you run "docker pull jenkins" - it will be grabbing this image. This is based on the current LTS (and will be kept up to date with the LTS) - but does not include the weekly releases (yet). Having a jenkins image that is fairly basic (it includes enough to run some basic builds, as well as jenkins itself) built on the LTS, on the latest LTS of Ubuntu seemed quite convenient - and easy to maintain using the official Ubuntu/Debian packaging of Jenkins.
Docker is a great way to try and use server based systems - it brings all the dependencies needed and the images actually are portable (ie anywhere docker runs you can run docker images). There are official images for many popular server platforms (redis, mysql, all the linux distros and so on) so it seemed crazy to not include Jenkins along with this list. "docker run -p 8080:8080 jenkins" is all you need to get going with LTS Jenkins now. You can also use "docker run jenkins:1.554" to get the latest of that lineage of LTS releases, or pick a specific one: "docker run jenkins:1.554.3" if you like. Leaving off a version assumes the latest. Check the tags page to see what is available.
You can read more and see how you can use it here.
There has been some questions and discussions on how to make use of Jenkins with the docker hub for creating new and interesting docker image based workflows for deployment. In fact, Jenkins featured in one of the first slides of the first keynote of docker con: To make this dream a reality some additional plugins had to be created - but this leaves the possibility of working with the docker hub (builds, stores images) and Jenkins (workflow, testing, deployment) to build out some kind of a continuous pipeline for handling docker based apps. I attempted to describe this more here.
It will be interesting to watch this grow and change.
I'll talk about my recent chef/puppet integration work in Jenkins. Sven from Perforce will talk about how to leverage Perforce features from Jenkins, and then James Nord will talk about workflow. It will be a worthy 2 hours.
If the line up of talks will not be enough to sway you, you should also know that I will bring some Jenkins give-aways!
I'm not sure how many people to expect, but there's a cap at 80 people, so if you are thinking about coming, be sure to RSVP. Looking forward to seeing many of you there!
Finally, if you are in London, the usual suspects (CloudBees, PuppetLabs, XebiaLabs, MidVision, SOASTA, et al) are doing a free event titled "How To Accelerate Innovation with Continuous Delivery" that you might also be interested in.
This is a guest post from Tom Fennelly
Over the last number of weeks we've been trying to "refresh" the Jenkins UI, modernizing the look and feel a bit. This has been a real community effort, with collaboration from lots of people, both in terms of implementation and in terms of providing honest/critical feedback. Lots of people deserve credit but, in particular, a big thanks to Kevin Burke and Daniel Beck.
Current / Old Look & Feel
New Look & Feel
Among other things, you'll see:
- A new responsive layout based on <div> elements (as opposed to <table> elements). Try resizing the screen or viewing on a smaller device. More to come on this though, we hope.
- Updated default font from Verdana to Helvetica.
- Nicer form elements and nicer buttons.
- Smoother side panels e.g. Build Executors, Build Queues and Build History panes.
- Smoother project views with more modern tabs.
You might already be seeing these changes if you're using the latest and greatest code from Jenkins. If not, you should see them in the next LTS release.
We've been trying to make these changes without breaking existing features and plugins and, so far, we think we've been successful but if you spot anything you think we might have had a negative effect on, then please log a JIRA and we'll try to address it.
One thing we've "sort of" played with too is cleaning up of the Job Config page - breaking into sections and making it easier to navigate etc. This is a big change and something we've been shying away from because of the effect it will have on plugins and form submission. That said, I think we'll need to bite the bullet and tackle this sooner or later because it's a big usability issue.
My favorite part is, to quote, "Jenkins has an almost laughably dominant position in the CI server segment", and "With 70% of the CI market on lockdown and showing an increasing rate of plugin development, Jenkins is undoubtably the most popular way to go with CI servers."
If you want to read more about it and other 9 technologies that won, they have produced a beautifully formatted PDF for you to read.
Some time ago, we've built Jenkins bobble head figures. This was such a huge hit that everywhere I go, I get asked about them. The only problem was that it cannot be individually ordered, and we didn't have enough cycles to individually sell and ship them for those who wanted them.
So I decided to have the 3D model of Mr.Jenkins built, which would allow anyone to print them via 3D printer. I comissioned akiki, a 3D model designer, to turn our beloved butler into a fully-digital color-printable figure. He was even kind enough to discount the price with the understanding that this is for an open-source project.
The result was IMHO excellent, and when I finally came back to my house yesterday from a two-weeks trip, I found it delivered to my house: With the red bow tie, a napkin, a blue suit, and his signature beard, it is instantly recognizable as Mr.Jenkins. He's mounted on top of a red base, and is quite stable. I think the Japanese sensibility of the designer is really showing! Note that the material has a rough surface and it is not very strong, but that's what you trade to get full color.
I've put it up on Shapeways so that you can order it yourself. The figure is about 2.5in/6cm tall. The price includes a bit of markup toward recovering the cost of the design. My goal is to sell 25 of them, which will roughly break it even. Any excess, if it ever happens, will be donated back to the project.
Likewise, once I hit that goal, I will make the original data publicly available under CC-BY-SA, so that other people can modify the data or even print it on their own 3D printers.
This year marks the 3rd annual Jenkins User Conference in Israel. While the timing of the event turned out to be less than ideal for reasons beyond our control, that didn't stop 400 Jenkins users from showing up at the "explosive" event at a seaside hotel near Tel Aviv.
Shlomi Ben-Haim kicked off the conference by reporting that JUC Israel just keeps getting bigger, and that we sold out 2 weeks earlier and the team had to turn down people who really wanted to come in. The degree of adoption of Jenkins is amazing in this part of the world, and we might have to find a bigger venue next year to accomodate everyone who wants to come.
It turns out most of the talks were in Hebrew, so it was difficult for me to really understand what's going on, but the talks ranged from highly technical ones like how to provision Jenkins from configuration management (the server as welll as jobs), all the way to more culture focused one like how to deploy CD practice in an organization. Companies large and small were well represented, and I met with a number of folks who actively contribute to the community.
There were a lot of hall way conversations, and those of us at the booth had busy time.
Thanks everyone who came, thanks JFrog for being on the ground for the event (and congratulations for the new round of funding) and CloudBees for hosting the event. Please let us know if there are things we can do better, and see you again next year!
One of the challenges of running Jenkins User Conferences is to ballance the interest of attendees and the interest of sponsors. Sponsors would like to know more about attendees, but attendees are often weary of getting contacted. Our past few JUCs have been run by making it opt-in to have the contact information passed to sponsors, but the ratio of people who opt-in is too low. So we started thinking about adjusting this.
So our current plan is to reduce the amount of data we collect and pass on, but to make this automatic for every attendee. Specifically, we'd limit the data only to name, company, e-mail, and city/state/country you are from. But no phone number, no street address, etc. We discussed this in the last project meeting, and people generally seem to think this is reasonable. That said, this is a sensitive issue, so we wanted more people to be aware.
By the way, the call for papers to JUC Bay Area is about to close in a few days. If you are interested in giving a talk (and that's often the best way to get feedback and take credit on your work), please make sure to submit it this week.
The other day I was explaining how to implement a new workflow primitive to Vivek Pandey, and I captured it as a recording.
The recording goes over how to implement the Step extension point, which is the workflow equivalent of BuildStep extension point. If you are interested in jumping on the workflow plugin hacking, this might be useful (and don't forget to get in touch with us so that we can help you!)