We have been featuring a few proposals this week for what " Jenkins 2.0" is going to include. Today we’ll be diving into the most noticeable changes being proposed for Jenkins 2.0: the User Experience (UX) improvements Thus far in this blog series we have reviewed proposals covering: Introducing a policy for API deprecation Splitting Groovy out of 'core' Pipeline as code front and center The UX improvements being proposed aren’t necessarily as uniform as the proposals from earlier in the week but represent a large amount of prototype and exploratory work done by folks like Tom Fennelly, Gus Reiber and a few others. Those following the dev list may have already seen some of these proposals in some of the "mega threads" that we have had discussing potential UI/UX improvements previously. The improvements proposed for 2.0 can be found under JENKINS-31156 . The most promising proposal under this issue is to update the plugin manager experience. Another very important proposal for 2.0 worth mentioning is the proposal to update UI work well on mobile devices. Providing Feedback We’re asking you to read the issues linked from JENKINS-31156 and comment and vote on those issues accordingly. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. Stay tuned for tomorrow’s post covering the remainder of the proposed user experience changes!

We have been featuring a few proposals this week for what " Jenkins 2.0" is going to include, today we’re discussing my personal favorite, which I believe will have a tremendously positive impact for years to come (not to be too biased!): moving the "Pipeline as Code" support in Jenkins to the front and center. Thus far in this blog series we have reviewed proposals covering: Introducing a policy for API deprecation Splitting Groovy out of 'core' Today’s proposal comes from project founder Kohsuke Kawaguchi titled " Pipeline as code front and center " and represents perhaps the most important and dramatic shift we hope to make in Jenkins 2.0. This functionality has existed through the workflow plugin, which we have discussed at various Jenkins events before but if you’re not aware of some of the power behind it, check out this presentation from Jesse Glick : The proposal in JENKINS-31152 expands on the problem we aim to address: The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves. To address this, Kohsuke is proposing that we : Introduce a new subsystem in Jenkins that: lets you design a whole pipeline, not just a single linear set of tasks stores the said pipeline configuration as human-editable Jenkinsfile in your SCM makes it automatic to set up new pipelines when Jenkinsfile is added differentiates multiple branches in the same repository This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today. Kohsuke’s proposal is largely about bringing together a lot of already existing pieces together to provide a very compelling experience for new and existing users alike. I hope it is clear now why this proposal is so exciting to me. Providing Feedback We’re asking you to read the proposal in JENKINS-31152, which itself have some additional tickets linked under it, and provide feedback if you have it. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. Stay tuned for a couple more posts covering proposals to improve the Jenkins interface and user experience!

As I mentioned in yesterday’s post, there’s been a lot of discussion recently about what " Jenkins 2.0" means. In a recent "Office Hours" session, Kohsuke Kawaguchi presented his vision for Jenkins 2.0 in a office hours session, the slides for which can be found in this Google Presentation. Roughly paraphrasing Kohsuke’s vision, 2.0 is primarily about making things better for the thousands of users out there. This week, we’ll be reviewing some key areas of the "Jenkins 2.0" proposal. Asking you, the user community, to provide feedback on these proposals, going from Jenkins internals to user interface. Thus far we’ve covered: Introducing a policy for API deprecation Today’s post involves a proposal originally from community member Jesse Glick who has proposed in JENKINS-29068 that Groovy be split out from the "core" Jenkins distribution. The linked issue expands on what the problem is here: Currently Jenkins embeds a distribution of Groovy into "core" for a variety of scripting and management tasks. This version of Groovy is locked into core in such a way that users cannot upgrade Groovy independently from Jenkins itself. If the Jenkins-bundled version were upgraded to a different major version, it may break users' custom scripts as well as plugins that use Groovy due to API changes. The proposal is relatively straight-forward and affects the many different users and use-cases for the embedded Groovy scripting support in Jenkins: For ease of maintenance and modularity it would be useful to split Jenkins' use of Groovy into a library plugin; different clients could request 1.x and 2.x simultaneously by using different versions of the library, etc. Stuff in core using Groovy that would need to either be put in this library (if infrastructure for other features) or put in another plugin depending on it (if first-class features themselves): I selected this proposal to feature on this blog, despite its rather technical underpinnings, it will affect core developers, plugin developers, power and casual users alike. I encourage everybody to read through the proposal and its potential impact on the issue tracker. Providing Feedback We’re asking you to read the proposal in JENKINS-29068 and provide feedback if you have it. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. Stay tuned for the rest of the week as we keep with our theme of going "from the inside out" and help us make Jenkins 2.0 great!

Over the past few weeks there has been a vibrant discussion happening on the jenkinsci-dev@ mailing list as to what " Jenkins 2.0" means. While Jenkins does not currently adhere to semantic versioning, the change of a major version number does indicate a major milestone for the community. Project founder, Kohsuke Kawaguchi presented his vision for Jenkins 2.0 in a office hours session, the slides for which can be found in this Google Presentation. Roughly paraphrasing Kohsuke’s vision, 2.0 is primarily about making things better for the thousands of users out there. This week, we’ll be reviewing some key areas of the "Jenkins 2.0" proposal. Asking you, the user community, to provide feedback on these proposals, going from Jenkins internals to user interface. Today’s post involves a proposal to introduce a policy for API deprecation from community members Oliver Gondža and Daniel Beck. Extensibility is the heart of Jenkins, but over the past ten years we’ve not had a proper API deprecation policy other than "try not to break plugins, ever." Daniel, expanding more on the problem wrote: We have no backward compatibility policy besides "compatibility matters". With 1000+ plugins and basically the entire core being available to plugins, a lot of difficult or impossible to remove cruft has accumulated over the last ten years. This limits both what can be changed in core, and makes documentation difficult to use for plugin developers. The two have put together a detailed proposal under JENKINS-31035 which suggests we: limit the availability in APIs (classes, methods, fields, …​) provided by core to a number of releases. Depending on the feature, this can range from a few months, to a few years (e.g. two years being about 100 releases of Jenkins and eight LTS baselines). […​] I highly encourage you to read the entire proposal on the issue tracker, where we are trying to collect feedback/history. Providing Feedback We’re asking you to read the proposal in JENKINS-31035 and provide feedback if you have it. If you have ever logged in to the issue tracker or the wiki, you have a "Jenkins user account" which means you’ll be able to log into the issue tracker and vote for, or comment on the issue linked above. ( note : if you have forgotten your password, use the account app to reset it.) We’re going to review feedback, make any necessary adjustments and either approve or reject the proposal two weeks from today. Stay tuned, and help make Jenkins 2.0 great!

For the past several years we’ve been attending FOSDEM, a massive free and open source event in Brussels, Belgium. In preparation for this upcoming FOSDEM (2016) event, we will be hosting an open planning meeting via Google Hangouts during this week’s " Office Hours." Agenda: Gauge who can participate and at what capacity. Pre-FOSDEM Contributor Summit After-hours meetup/happy hour Plans for a Jenkins stand (assuming we’re accepted): What demo materials Schwag Revised Jenkins Flyer The FOSDEM 2016 wiki page is where we will be recording plans and tasks will be added to JIRA. If you cannot join us via the FOSDEM Office Hours Hangout , we will also be watching the #jenkins-community channel on the Freenode network if you cannot participate directly. Please join us on this Google Hangout at 11:00 a.m. PDT this Wednesday (Oct 21)

Earlier this year we participated in FOSDEM 2012 in Brussels, Belgium. Overall the event was a major success and we’re very happy we were able to take part in it! For FOSDEM 2013, we’ll be back in Brussels and participating in a major way. The first day of FOSDEM (February 2, 2013) will be the 2nd birthday for the Jenkins project, and seems appropriate that project founder Kohsuke Kawaguchi will be giving a keynote session titled: " How we made the Jenkins community " Here’s an excerpt from Kohsuke’s talk proposal: Jenkins project has an interesting history. It started from scratch on my spare time, and grow over time to boast 600+ open-source plugins developed by 300+ contributors from all around the world. There are several key ingredients, both technical and social, that enabled this model, and I think those ingredients are useful to other projects. In this talk, I’ll discuss how Jenkins project and the community works, what these ingredients are, why they help you attract more developers into your projects, and why it matters. You can read more about Kohsuke’s keynote here In addition to the keynote, I ( R. Tyler Croy), and a number of members of the Jenkins, Cucumber and Selenium communities are hosting the first ever Testing and Automation devroom at FOSDEM. If you’re interested in submitting a talk proposal for the dev room the deadline is 23:59 UTC on December 21st 2012! The Call for Proposals can be found here, and the proposal submission form can can be found here. We are very likely going to have a table in the hall again this year, but the FOSDEM committee hasn’t yet confirmed whether or not we will have a table. Regardless, a lot of Jenkins community members will be at FOSDEM in February in addition to hundreds of other open source contributors and users from around the world. If you’re interested in participating and/or meeting up with the Jenkins crowd, there’s details coming together on the FOSDEM wiki page . We hope to see you there!

Recently, Jenkins User Conference organizer Alyssa Tong sent out the following request: Jenkins User Conf SF is looking for volunteers to help us record the sessions. Pls drop me an email if you’re able to help. We’re trying to make sure we can capture video of as much of this year’s conference as possible, but the only way we can do that is with your help! If you’ll be in town for JavaOne, or just live in the bay area, drop Alyssa an email at atong@cloudbees.com.

We have hosted two informal meetups introducing Jenkins Continuous Integration Server. The first in end of June (announced here on this blog) and the second on the 7th of August. The first meet-up in June was only announced 8 days before, but had very good attendance - the second was completely booked (15 seats). The agenda is a short presentation of continuous integration and software validation to inspire the use of Jenkins, then a few words and terms about Jenkins and finally a live demo. The live demo starts from scratch by downloaded the latest Jenkins java web archive, starts it, define a job on one of our Maven based java projects on Github. We add two easy plugins (Warnings and Task Scanner). Second part of the demo is about unit testing and coverage and we show how easy it is to enable a JUnit report and add a Cobertura coverage report if there is already unit tests for the project. The meetups have about 90 minutes scheduled, including questions and the discussion session after the demo, where we serve pizza, beer and cola. The theoretical presentation and live demo is typically finished within one hour, even though we encourage our guests to ask questions and discuss whatever comes into their mind on the way. The relatively short time used for the introduction demonstrates how easy it is to get started with continuous integration and software validation using Jenkins. As the live demo is based on a Java/Maven project we ask the guests about their technologies and try to relate that to their setup, so they know there also is an easy approach for them to use Jenkins. The meeting is quite informal, and limited to 15 participants, leaving plenty of time to dicsuss and answer questions both before and after the meeting. We are always a few developers from Praqma to facilitate the discussions about the participants individual setup and questions. These informal discussions are one of the main gains for us in Praqma, as it is very interesting to share our experience with our guests and hear about all of their interesting challenges, that might have brough them north of Copenhagento attend our meeting. Because these first meet-ups have been so popular and interesting we have decided to arrange them regularly in the future. Not just the Jenkins introduction, which will be repeated as long as there is an interest, but we are also making plans for meetups about Git, Mercurial and other topics. If you’re interested in more Jenkins and CI related meet-ups in the Copenhagen area, visit our homepage or follow the #pragma hashtag on Twitter. We also have a Jenkins User Event in Copenhagen coming in September.