Congratulations! The Jenkins project officially went over the 100K active users mark sometime in January. As of January 31, we were at 102,992. YOU are one of the 100K active users! As discussed on a couple recent project meetings, we have designated February 26 as Jenkins Celebration Day. To make some noise, here is what we are doing starting NOW: Write a blog about anything related to Jenkins. Post your blog and Tweet out a link to it. Include the hashtag #Jenkins100K in your post. On February 26, we will hold a raffle and pick four names at random. The grand prize winner will get a 3D Jenkins Butler model. Five others will get their pick of Jenkins swag (up to $20) from the Jenkins online store. OTHER WAYS TO CELEBRATE There are a number of other things planned and we want YOU to be involved. This blog post is the central place to come for all things related to the celebration. Recording – Jenkins Governance Board Dean, Tyler, Andrew and I will get together this month and record some thoughts about the Jenkins project. We will share that recording with you from this page on February 26. Twitter Badge For those of us on social media that want to proudly celebrate our community, we will have a special badge that you can use for your profile image on Twitter or any of the other social media forums. Feel free to use the badge as long as you want – but let’s get as many of us using it as possible between now and February 27. Social Media Images CloudBees is donating a series of images that we can all push out on social media (whatever platform(s) you use). Pick your favorite(s) and push them out on Twitter, Facebook, G+ Certificate (available on this blog post soon) Download your very own “I am part of the Jenkins 100K” certificate. Print it out and proudly display it on the wall of your cube or office. Visibility The Community will also issue a press release on February 26 announcing our milestone news. Sign the “card” Consider this blog a Congratulations card to the entire community. Share your thoughts in a comment on this blog about anything Jenkins-related that you wish! This is a big milestone for the Community and one you should be proud to be part of! Let’s make some noise…

+ https://plus.google.com/events/c4eagqodepqojlrv7glhc1ctg48[In tomorrow's Jenkins office hours], Jesse Glick will talk about two topics in the workflow plugin that he has been asked about: + + Security model: script security, permissions Plugin compatibility: SimpleBuildStep and friends, custom steps, etc. + + + The session should be interesting to anyone using workflow or thinking about using workflow. Jesse is one of the top contributors in the community, so it'd be definitely worth your time! +

+ A lot of us has grown fond of our loyal butler Mr.Jenkins over time, which was created by https://frontside.io/[Frontside] and chosen as https://jenkins-ci.org/content/the-polls-are-open-for-the-jenkins-logo-contest[a result of a logo contest]. In the true open-source style, the logo has since evolved into many different derivative works, such as https://wiki.jenkins.io/display/JENKINS/Emotional+Jenkins+Plugin[a plugin], https://jenkins-ci.org/content/jenkins-figure-available-shapeways[a 3D model], and https://jenkins-ci.org/content/behind-scenes-jenkins-user-conference-palo-alto[a bobble head]. + + + Our friends at CloudBees are running a https://twitter.com/search?q=%23BreakingBuilds[#BreakingBuilds] social media contest through Jan 5th to have some fun with Mr.Jenkins. https://ow.ly/FbZDb[Read Sacha Labourey's blog post], where he draws parallels between what a butler does and what continuous delivery can do. + + + I especially agree with him on this point: + + + I always loved the idea of using a butler to represent what Jenkins is about, as it projects all of the qualities that define continuous delivery: it is built to be proactive, it will help you fix problems before they happen, it orchestrates your entire pipeline to production without you having to worry about the sophisticated underlying sequence of steps and, if things go wrong Jenkins uses his fingerprint database to trace back the source of the issue. Full service. As your right arm, Jenkins is the reliable and trustworthy guy you want on your team! + + + + https://ow.ly/FdEBD[Check out the contest rules] and participate. Let's raise the visibility of Jenkins and have some fun in the process! + + Read Sacha’s blog Learn more about the contest and how to win Jenkins prizes Go directly to the #BreakingBuilds images +

Jenkins started with a notion of jobs and builds at heart. One script is one job, and as you repeatedly execute jobs, it creates builds as records. As the use case of Jenkins gets more sophisticated, people started combining jobs to orchestrate ever more complex activities. A number of plugins have been developed to enable all sorts of different ways to compose jobs, and many are used quite successfully in production. But this resulted in a certain degree of complexity for users to figure out how to assemble these plugins. So we felt the need to develop a single unified solution that subsumes all these different ways to orchestrate activities that may span across multiple build agents, code repositories, etc. Various inputs from users as well as other plugin developers played a key role. The result of this is the workflow plugin, which is what a number of us, including Jesse Glick an myself, are focused on in the past few months. The plugin approaches the problem by defining a DSL for you to describe an execution of a job. Various convenient primitives are available, such as executing shell scripts, checking out the source code, obtaining an executor or a build workspace, etc. All sorts of classic existing plugins contribute their functionalities into this DSL, such as recording test results, fingerprints, or calling into other existing jobs. This allows you to leverage higher-level functionalities and report comprehension capability into a workflow. Similarly, you can leverage the ability of Groovy, the host language of workflow DSL, to define control flows, abstractions, and reuse. A key feature of a workflow execution is that it’s suspendable. That is, while the workflow is running your script, you can shut down Jenkins or lose a connectivity to a agent. When it comes back, Jenkins will still remember what it was doing, and your workflow script resumes execution as if it was never interrupted. A technique known as the " continuation-passing style" execution plays a key role in achieving this. I’m very happy to report that the workflow plugin is finally 1.0. This version runs on the latest 1.580-based LTS. and we created a docker image for you to play with too. There’s also a JUC presentation that explains this. We are working toward 1.0 release within this year, and in the meantime, the syntax is stable enough to allow you to start designing workflows today. We’ve been hearing a lot of good feedbacks and enthusiasm for this new effort. Please let us know what you think.

This is a guest post by Craig Rodrigues The FreeBSD project produces a modern operating system derived from BSD Unix. In the past 6 months, we have set up Jenkins at https://jenkins.freebsd.org/, to continuously build FreeBSD as developers add new code to the project. This has helped us identify and fix build breaks very quickly. We have gone even farther by integrating Jenkins, Kyua, and Bhyve. Kyua is a testing framework for infrastructure software. Bhyve is the native hypervisor that comes with FreeBSD (similar to KVM on Linux). We use the Build Flow plugin in this example Build flow to do the following: Build the FreeBSD kernel and userland on amd64 whenever someone checks in new code to https://svn.freebsd.org Create a bootable FreeBSD disk image with makefs Boot the image under bhyve Run these commands inside the bhyve VM: cd /usr/tests; kyua test; kyua report-junit --output=test-output.xml Shut down the bhyve VM Imports test-output.xml into Jenkins. Produces a full native test report in Jenkins The results of this work were presented at the Bay Area FreeBSD Users Group in this presentation in October 2014. Jenkins has been very easy to set up and use under FreeBSD. We hope that by using Jenkins to run OS-level unit tests, we will be able to improve the quality of FreeBSD. For further information, please feel free to contact us at freebsd-testing@FreeBSD.org.

+ Jenkins User Conference in Bay Area is this Thursday, and one of the new things this year is the mobile app. + + + https://doubledutch.me/download/jenkins-user-conference[ + image:https://dl.doubledutch.me/images/downloadiphone.png[image,width=253,height=532] + ] + + + + There's an Android version as well as an iPhone version. I've installed it locally, and it's very handy for checking the agenda, get more info about speakers and sponsors.

+ https://en.wikipedia.org/wiki/Poodle[image:https://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Freddie_%288467901543%29.jpg/160px-Freddie_%288467901543%29.jpg[image]] + + + + Another day, another SSL vulnerability! Google has https://poodle.io/[announced a vulnerability in SSL v3], and if you are using the "Winstone" servlet container built into Jenkins, and if you are using the HTTPS connector with the `+--httpsPort+` option (it is off by default), then you are vulnerable to this problem. + + + I've just issued link:/security/advisory/2014-10-15/[a security advisory] on this. If you haven't already subscribed to https://wiki.jenkins.io/display/JENKINS/Security+Advisories[the Jenkins security advisory mailing list], this is a great opportunity to do so. + + + + The advisory includes the target delivery vehicles for the fix and how you can address the problem in the mean time. Inside corporate intranet, where Jenkins is typically used, I suppose there's a degree of trust among participants to make this less of a problem. But if you run an internet facing Jenkins, be sure to deploy the fix. + + + + (And as I write this, I've fixed all the `+https://*.jenkins-ci.org+` servers to disable SSLv3, so we are covered there)

(This is a guest post from Daniel Spilker) Jenkins supports building plugins using Gradle for a while now. Last week a new version of the Gradle JPI plugin has been released to iron out some issues. The Gradle JPI plugin enables a 100% groovy plugin development environment with Groovy as primary programming language, Spock for writing tests and Gradle as build system. Have a look at the Job DSL plugin for an example. An existing Maven build can be converted to Gradle by using the build.gradle template from the Gradle JPI plugin’s README. For instance, the POM from the Gradle plugin translates to this build.gradle file: buildscript { repositories { mavenCentral() maven { url 'https://repo.jenkins-ci.org/releases/' } } dependencies { classpath 'org.jenkins-ci.tools:gradle-jpi-plugin:0.6.0' } } apply plugin: 'jpi' group = 'org.jenkins-ci.plugins' version = '1.25-SNAPSHOT' jenkinsPlugin { coreVersion = '1.480' displayName = 'Jenkins Gradle plugin' url = 'https://wiki.jenkins.io/display/JENKINS/Gradle+Plugin' gitHubUrl = 'https://github.com/jenkinsci/gradle-plugin' developers { developer { id 'gbois' name 'Gregory Boissinot' timezone '+1' } } } dependencies { compile 'org.jenkins-ci.lib:dry-run-lib:0.1' } Usage of the Gradle JPI plugin is similar to working with the Maven HPI plugin. Use gradle jpi to build the plugin file. gradle check runs the tests, gradle install copies the plugin into the local Maven repository, gradle uploadArchives deploys the plugin to the Jenkins Maven repository and gradle server starts a Jenkins development server with the plugin installed. It is recommended to use Gradle 1.8 because that is the version used to build and test the Gradle JPI plugin. For the next release it is planned to do some maintenance like fixing code style issues and adding tests. After that more issues need to be addressed to bring the plugin on par with the Maven HPI plugin, most notably fixing the test dependencies ( JENKINS-17129) and publishing the plugin’s JAR ( JENKINS-25007). Updating Gradle to 2.x and getting the plugin on the Gradle plugin portal is also on the wishlist.