We just released security updates to Jenkins, versions 2.89 and 2.73.3, that fix two low-severity security vulnerabilities.
For an overview of what was fixed, see the security advisory. For an overview on the possible impact of these changes on upgrading Jenkins LTS, see our LTS upgrade guide.
Subscribe to the jenkinsci-advisories mailing list to receive important notifications related to Jenkins security.
Regular perusers of the Jenkins User Documentation may have noticed the presence of the Tutorials part (between the Guided Tour and User Handbook) that appeared in the last couple of months and gradually began to get populated with much of my recent work, writing Jenkins tutorials.
My name’s Giles and I’ve been a technical writer in the software development field for several years now. I’ve always been passionate about technical writing and more recently, the technologies that go into developing written content and automating its generation - like Jenkins! I was a former Atlassian and recently joined CloudBees as a Senior Technical Writer, working remotely from the "Sydney Office", with my current focus on the Jenkins User Documentation.
My exposure to Jenkins and its usage over the years has been patchy at best. During this time, however, I’ve had some degree of experience as a user of various continuous delivery (CD) tools like Jenkins and am reasonably familiar with the advantages these tools can offer software development teams.
I’ve also found that while many software developers are familiar with the broader concept of "developer operations" (or simply "devops"), fewer seem familiar with the concepts of CD and related tools to facilitate devops within organizations.
The CD process is based on the fundamental flow of building the application>testing it> delivering it, where typically:
The building part involves compiling the application and/or ensuring all necessary libraries and dependencies are in place for the application to run as intended.
The testing part involves testing the built application with automated tests to ensure that changes implemented by developers function as expected.
The delivering part involves packaging or presenting the application in a way that can be delivered to customers or other users for any kind of purpose.
Now, as one of the major contributors to the Jenkins User Documentation (and faced with a reasonably steep learning curve), it quickly became apparent about the lack of accessible documentation to hand-hold people relatively new to Jenkins through this CD process. I couldn’t find anything in the Jenkins User Documentation to demonstrate how Jenkins implements this process on a simple app that delivers an end result.
With the guidance and assistance of helpful colleagues, I therefore decided to embark on creating a series of Jenkins tutorials to help fill these documentation and knowledge gaps. These tutorials are based on Daniele Procida’s description of how tutorials should be presented in his blog post "What nobody tells you about documentation").
The first set of tutorials on the Tutorials overview page demonstrate how to implement this fundamental CD process in Jenkins on a simple application for a given technology stack.
So far, there’s one for Java with Maven and another for Node.js and React with npm. Another for Python will be added to this list in the near future.
These tutorials define your application’s entire CD process (i.e. your Pipeline)
in a Jenkinsfile, whose Groovy-like Declarative Pipeline syntax is checked in
to your Git source repository. Managing your Pipeline with your application’s
source code like this forms the fundamentals of "Pipeline as code".
The Introductory tutorials also cover how to use some powerful features of Jenkins, like Blue Ocean, which makes it easy to connect to an existing cloud, web or locally hosted Git repository and create your Pipeline with limited knowledge of Pipeline syntax.
Also soon to be released will be the first Advanced tutorial on building
multibranch Pipelines in Jenkins. This tutorial takes the "Pipeline as code"
concept to a new level, where a single Jenkinsfile (defining the entire CD
process across all branches of your application’s Git repository) consists of
multiple stages which are selectively executed based on the branch that Jenkins
is building.
Additional tutorials that demonstrate more advanced features of Jenkins and how to manage your Pipelines with greater sophistication and flexibility will be added to this section in future.
You can access all currently available tutorials from theTutorials overview page in the Jenkins User Documentation. It’s worthwhile checking that page from time to time as it’ll be updated whenever a new tutorial is published.
Also, if you have any suggestions for tutorials or other content you’d like to
see in the documentation, please post your suggestions in the
Jenkins
Documentation Google Group, which you can also post (and reply) to by emailingjenkinsci-docs@googlegroups.com.
The Sydney Office team meeting at Carriageworks - from left to right, Giles
Gaskell, Nicholae Pascu, Michael Neale and James Dumay
This is a guest post by Forest Jing, who runs the Shanghai Jenkins Area Meetup |
The first Jenkins User Conference China was held on November 19, 2017 in Shanghai, China. It was an amazing conference for Jenkins users in China. There were almost 450 attendees to enjoy a lovely day with Jenkins creator, Kohsuke Kawaguchi.
There were 12 wonderful presentations, 1 workshop and 1 open space to set the stage for JUC China. The day began with Kohsuke, welcomed to the stage by all the attendees here with their warm applauses. All of them are fans of Jenkins and Kohsuke. Thanks to Kohsuke, he made a wonderful presentation to show the past, present and future of Jenkins for Chinese Jenkins users.
The co-founder of DevOps Times community, Le Zhang released a report of adoption of Deployment Pipeline in Chinese IT organization. The report shows that Jenkins is the most popular tool for DevOps and CD in China.
It also has proven that “If it hurts, do it more often!” is right because the IT organization who deploy more frequently, deployment failure would be less.
The Three Musketeers of DevOps in China (Le Zhang, Xuefeng Shi,Forest Jing) have demonstrated a DevOps pipeline based on Jenkins and many open-source software such as Kubernetes, Gitlab, etc.
After the presentation, lots of fans waited in line to take pictures with Kohsuke.
Here are some photos of the JUC China. We really enjoyed it.
Lastly, as an organizer for JUC China, I would like to thank Kohsuke Kawaguchi, Alyssa Tong, Sam Van Oort and so many friends from CloudBees and Jenkins community to have given us so many help to make the first JUC China an amazing and successful conference for Jenkins users in China. We look forward to organizing many more JUC China.
We just released security updates to Jenkins, versions 2.95 and 2.89.2, that fix two security vulnerabilities. For an overview of what was fixed, see the security advisory.
We usually announce core security updates well in advance on the jenkinsci-advisories mailing list, to give Jenkins administrators time to schedule a maintenance. Additionally, we try to align security updates with the regular LTS schedule. We have chosen not to do so in this case for two reasons:
The random failure to set up Jenkins is very noticeable, and given that we’ve seen automated exploits for unprotected Jenkins instances in the past we consider it important to fix that issue as soon as possible, so that users setting up new instances of Jenkins can be confident they won’t start up insecurely.
The CSRF issue appears to only affect instances for a very short (seconds at most, if at all) time period immediately after startup, so administrators could apply the fix during the next scheduled Jenkins downtime, rather than immediately.
This is a guest post by Sanil Pillai, Director of Labs & Strategic Insights, Infostretch |
Infostretch has created aplugin for teams upgrading from Freestyle Jobs to Pipelines as code with Jenkins Pipeline. This new plugin streamlines the process and accelerates pipeline on-boarding for any new set of applications. Previously, when upgrading to Jenkins Pipeline, converting Freestyle Jobs required developers to drill down on each one of those hundreds (or thousands!) of jobs to understand tools, configurations, URLs, parameters, and more before rewriting them inPipeline syntax. This process is very manual, error-prone, lengthy, and not cost-effective. Beyond saving time, the new plugin also assures adherence to proper coding standards and separates complex business logic and standards declaration from execution flow.
Key features:
Convert single freestyle job to pipeline
Convert chain of freestyle jobs to single pipeline
Works with both Jenkins and CloudBees Jenkins Enterprise
Plugin can be customized to support any Freestyle plugin and an organization’s Pipeline Shared Library, or Groovy coding standards.
Works with CloudBees' Role-based Access Control to help the new Pipelines comply with existing security policies.
Direct migration of properties such as "Build with Parameters" to newly created Pipelines.
Direct migration of Agent on which job is to be run with support for multiple agent labels across different downstream jobs
Environment properties: JDK, NodeJS
Supports Git SCM.
Build steps: Maven, Ant, Shell, Batch, and Ansible Playbook.
Post build actions: artifact archiver, simple mailer, TestNG reports, JUnit reports, checkstyle publisher
Now, let’s take a look at how to get started:
Click on a link at Root level or Folder level or Job level.
Select the job from the drop-down list that is the beginning point of the "chain". If job level link is clicked, this drop-down list will not be visible.
Provide the new pipeline job name. If this is not specified, the plugin will attempt to create a new pipeline job with the naming convention of "oldname-pipeline".
Check "Recursively convert downstream jobs if any?" if you wish to have all the downstream jobs converted into this new pipeline. The plugin will write all the logic of current and downstream jobs into a single pipeline.
Check "Commit Jenkinsfile?" if you would like the plugin to create a Jenkinsfile and commit it back to the SCM. The plugin will commit the Jenkinsfile at the root of the SCM repository it finds in the first job (selected in step 1 above). It will attempt to commit to this repo using the credentials it finds in the first job.
Do note that the plugin will checkout the repo in to a temporary workspace on the master (JENKINS_HOME/plugins/convert-to- pipeline/ws). Once the conversion is complete and Jenkinsfile is committed back to the repo, the workspace will be deleted.
Click "Convert" to convert the Freestyle job configurations to a single scripted pipeline job. Once the conversion is complete and the new job is created, you will be redirected to the newly created pipeline job.
That’s it!
To learn more about plugin usage, customization and to see a demo click here to watch the webinar replay on-demand.
Jenkins project congratulates all users and contributors with the New Year! Let’s take a look at some changes this year.
We released major features like BlueOcean and Declarative Pipeline
These features offer a new user experience in Jenkins Web UI, powered by Jenkins Pipeline.
In Jenkins 2.54 we updated the Java minimal requirement to Java 8 (announcement).
Plugin CI has been moved to our Jenkins-on-Jenkins instance. All plugins are being built by Jenkins Pipeline with a special pipeline library
We adopted the Jenkins Enhancement Proposal (JEP) process for major changes in Jenkins. There are already JEPs under review:
In 2017 we had 60 weekly and 13 LTS releases with 305 fixes/enhancements only in the core.
Next week Jenkins is going to hit the 2.100 version, and the core changed greatly since the 2.0 release in April 2016.Jenkins Security was one of the hottest areas this year, there were 7security advisories for the core and 15 - for plugins.
For comparison, in 2016 there were only 6 security releases in total.
There were 2605 plugin releases, and >215 NEW plugins have been hosted in the Update Center. In particular Jenkins ecosystem has greatly expanded into the Cloud space by offering dozens of new plugins (e.g. for Azure and Kubernetes). We also got many new plugins providing integrations with various Development and DevOps tools.
Other subprojects and Jenkins components also got major updates. For example,Jenkins Remoting got 15 releases with stability improvements.Stapler Framework also got 6 releases.
Keep updating, Jenkins 2 is not only about Pipeline as Code!
This year we got many new Jenkins Area Meetups. Currently there are 77 meetups with more than 20,000 members in total (full map). More than 100 meetups have been organized around the globe.
There were also several Jenkins-focused conferences including the following ones:
Jenkins World in San-Francisco
Days Of Jenkins in Gothenburg and Oslo
Jenkins Community Day in Paris
Jenkins Days in Amsterdam
CloudBees | Jenkins Automotive and Embedded Day in Stuttgart
Next year we will have traditional contributor meeting at FOSDEM and at Jenkins World 2018. If you are interested in Jenkins, stop by at our community booths and join the contributor summits/hackathons. We also want to participate in Google Summer of Code 2018, and currently we are looking for mentors.
Stay tuned, there is much more to come next year!
FOSDEM 2018 is a free event for software developers to meet, share ideas and collaborate. It is an annual event that brings open source contributors from around the world for two days of presentations, discussions, and learning.
Jenkins will be well-represented at FOSDEM 2018.
We’ll have a happy hour Friday evening before FOSDEM at Cafe Le Roy d’Espagne. See the meetup page for details.
A Jenkins table will be staffed by volunteers at FOSDEM to answer questions, discuss topics, and help users. See the meetup page for details.
A Jenkins Hackfest will be held the day after FOSDEM 2018. Those who would like to join us for the hackfest 5 Feb 2018 should register for the meetup.
Meals, snacks, and beverages will be provided for the hackfest. Come join us, and let’s write some code!
Questions? feel free to contact Alyssa Tong or Mark Waite.
This year the Jenkins project is interested in participating inGoogle Summer of Code (GSoC). As in 2016/2017, we are looking for mentors. So yes, we are looking for you :)
GSoC is an annual international program which encourages college-aged students to participate with open source projects during the summer break between classes.
Students accepted into the program receive a stipend, paid by Google, to work on well-defined projects to improve or enhance the Jenkins project. In exchange, numerous Jenkins community members volunteer as mentors for students to help integrate them into the open source community and succeed in completing their summer projects.
A student who works full-time in the area of your interest for several months
Joint projects with Jenkins experts, lots of fun and ability to study something together
Limited-edition of swags from Google and Jenkins project
Maybe: Participation in GSoC Mentor Summit and other GSoC events/meetups
Mentors are expected to…
Be passionate about Jenkins
Lead the project in the area of their interest
Actively participate in the project during student selection, community bonding and coding phases (March - August)
Work in teams of 2+ mentors per 1 each student
Dedicate a consistent and significant amount of time, especially during the coding phase (~5 hours per week in a team of two mentors)
Mentorship does NOT require strong expertise in Jenkins plugin development. The main objective is to guide students and to get them involved into the Jenkins community. GSoC org admins will help to find advisors if a special expertise is needed.
Disclaimer: We cannot guarantee that the Jenkins organization gets accepted to GSoC. Even if it gets accepted, we may need to select projects depending on student applications and the number of allocated project slots. |
Dec 2017 - started collecting project ideas
Jan 17 - Status review at the Jenkins Governance Meeting. Outcome: decision whether we apply to GSoC in 2018.
Jan 21 - Application to GSoC (deadline - Jan 23)
Feb 12 - List of accepted mentoring organizations published
Mar 05 - Deadline for project idea proposals
Next - GSoC Timeline
If you are interested in proposing a project or joining an existing one, please respond tothis thread in the Jenkins Developer mailing list. We aggregate/review proposals inthis document where you just need to describe the idea and introduce yourself.
Please propose new project ideas for discussion until March 05. You can join an existing project at any time, including community bonding and coding periods.
GSoC is about code (though it may and likely should include some documentation and testing work)
Projects should be about Jenkins (plugins, core, infrastructure, integrations, etc.)
Projects should be potentially doable by a student in 3-4 months
You can find more information about requirements and practices in theGSoC Mentor Guide.
Last week, buddybuild — a hosted continuous integration service focused on mobile apps — announced that it had been acquired by Apple, and consequently its complete Android offering, along with its free tier for iOS users, will be discontinued at the beginning of March.
This was a fairly undesirable way to start 2018 for buddybuild’s Android users and, with less than two months to find an alternative, many took to Twitter to simultaneously congratulate buddybuild on their acquisition, and commiserate with others who have to find a new way to build and test their app.
While Jenkins is usually deployed as a self-hosted solution (with over 150k installs), rather than a hosted service like buddybuild, we thought this would be a good time to highlight — thanks to the rich plugin ecosystem of Jenkins — some of the possibilities offered to Android developers by Jenkins.
Android projects are fundamentally no different from how other types of software development projects might make use of a Continuous Integration & Continuous Delivery system (CI/CD) such as Jenkins: Android developers will collaborate using a source control management system (SCM) such as Git or Mercurial; they will create Pull Requests, which should be automatically verified; they expect to get feedback on test failures and code quality (e.g. via email or Slack); and they should be able to easily deploy new versions of their app to beta testers or end users.
To this end, Jenkins lets you define your build and deployment pipelines in a structured and auditable fashion (via Jenkinsfile), supports a multitude of SCMs, while the multibranch Pipeline feature automatically creates new Jenkins jobs for every new Pull Request in your repository, and cleans them up as branches get merged. The Blue Ocean user interface ties these features together in a clean, modern UI.
To build an Android app, you need the Java development tools (JDK), which Jenkins can automatically install for you, plus the Android SDK, which you can also install on individual build agents using a tool installer, or you can use a Docker container with the Android SDK Tools preinstalled, for example.
Then, you can use your SCM plugin of choice to fetch your source code, and build the app using the Android Gradle Plugin via the Gradle Wrapper— in most cases this is as simple as running ./gradlew assembleDebug.
Once your app has been built and packaged into a .apk file, you can use the archiveArtifacts build step, storing the APK, enabling colleagues to download APKs directly from Jenkins, so that they can try out the latest build.
The Android SDK supports two types of test: unit tests, which run on the JVM, and instrumentation tests, which have to run on an Android device or emulator. Both types of test can be executed using Jenkins and, since the Android Gradle Plugin writes the test results to disk in JUnit XML format, the JUnit Plugin for Jenkins can be used to parse the results, enabling you see a test report, and to be notified of test failures.
Compiling and executing the unit tests for your app is as simple as adding another build step which runs ./gradlew testDebugUnitTest.
Similarly, instrumentation tests can be compiled and executed via the connectedDebugAndroidTest task in Gradle. However, before you do this, you should ensure that an Android device is connected to your Jenkins build agent, or you can make use of the Android Emulator Plugin to automatically download, create, and start an emulator for you during a build. There are also plugins for cloud testing services such as AWS Device Farm.
Once you have finished executing the tests, you can use the junit step to analyse the results: junit '**/TEST-*.xml'.
Similar to other Java or Kotlin projects, you can scan your codebase using static analysis tools like FindBugs or Checkstyle. Once again, Jenkins has analysis plugins which can parse the output of these tools, and present you with the results and trend graphs, or optionally flag the build as unstable or failed if too many problems have been detected.
The Android SDK provides a further useful static analysis tool called Lint. The output of this tool can be parsed by the Android Lint Plugin, which will analyse the issues found, and provide you with a detailed report within Jenkins. This functionality was demonstrated by the Android Tools Team at the Google I/O conference a few years back.
In order to distribute an Android app, it needs to be signed with a private key, which you should keep safe (losing it means you won’t be able to publish updates to your app!), and as secure as possible.
Instead of developers having to keep the signing keystore on their development machines, you can securely store the keystore and/or its passphrase on Jenkins using the Credentials Plugin. This avoids having to hardcode the passphrase into your build.gradle, or have it otherwise checked into your SCM.
The Credentials Plugin allows you to store secrets in Jenkins — which will be stored encrypted on disk when not in use — and those secrets can temporarily be made available during a build, either as a file in the build workspace, or exposed as an environment variable.
You can use such environment variables in a signingConfig block within your build.gradle, or you can make use of the Android Signing Plugin to sign your APK for you.
Once you have your production-ready APK built and signed, you can automatically upload it to Google Play using the Google Play Android Publisher plugin. The benefit of using this plugin is that it supports multiple APK upload, expansion files, uploading of ProGuard mapping files, promotion of builds from alpha, to beta, to production — and once again, your Google Play credentials are securely stored on Jenkins thanks to integration with the Credentials Plugin.
Here’s a straightforward example of a Jenkinsfile defining a pipeline to build, test, and optionally deploy an Android app, from a multibranch Pipeline job.
It requires the Pipeline, JUnit, Android Lint, Google Play Android Publisher, and Mailer plugins to be installed.
pipeline {
agent {// Run on a build agent where we have the Android SDK installed
label 'android'
}
options {// Stop the build early in case of compile or test failures
skipStagesAfterUnstable()
}
stages {
stage('Compile') {
steps {// Compile the app and its dependencies
sh './gradlew compileDebugSources'
}
}
stage('Unit test') {
steps {// Compile and run the unit tests for the app and its dependencies
sh './gradlew testDebugUnitTest testDebugUnitTest'// Analyse the test results and update the build result as appropriate
junit '**/TEST-*.xml'
}
}
stage('Build APK') {
steps {// Finish building and packaging the APK
sh './gradlew assembleDebug'// Archive the APKs so that they can be downloaded from Jenkins
archiveArtifacts '**/*.apk'
}
}
stage('Static analysis') {
steps {// Run Lint and analyse the results
sh './gradlew lintDebug'
androidLint pattern: '**/lint-results-*.xml'
}
}
stage('Deploy') {
when {// Only execute this stage when building from the `beta` branch
branch 'beta'
}
environment {// Assuming a file credential has been added to Jenkins, with the ID 'my-app-signing-keystore',// this will export an environment variable during the build, pointing to the absolute path of// the stored Android keystore file. When the build ends, the temporarily file will be removed.
SIGNING_KEYSTORE = credentials('my-app-signing-keystore')// Similarly, the value of this variable will be a password stored by the Credentials Plugin
SIGNING_KEY_PASSWORD = credentials('my-app-signing-password')
}
steps {// Build the app in release mode, and sign the APK using the environment variables
sh './gradlew assembleRelease'// Archive the APKs so that they can be downloaded from Jenkins
archiveArtifacts '**/*.apk'// Upload the APK to Google Play
androidApkUpload googleCredentialsId: 'Google Play', apkFilesPattern: '**/*-release.apk', trackName: 'beta'
}
post {
success {// Notify if the upload succeeded
mail to: 'beta-testers@example.com', subject: 'New build available!', body: 'Check it out!'
}
}
}
}
post {
failure {// Notify developer team of the failure
mail to: 'android-devs@example.com', subject: 'Oops!', body: "Build ${env.BUILD_NUMBER} failed; ${env.BUILD_URL}"
}
}
}While buddybuild concentrated on Android and iOS apps, thanks to the distributed build agent architecture of Jenkins, you can automate any type of project.
For example, you can expand the capabilities of Jenkins by adding macOS (or Windows, Linux, BSD…) agents; you can dynamically spin up agents on AWS EC2 instances, Microsoft Azure VMs, or Azure Container Instances; you can create agents using VMware, and so on.
Thousands of Jenkins instances are already using the various Android-related plugins, and Pipeline along with the Blue Ocean User Interface make using Jenkins simpler than it’s ever been.
Give Jenkins a try for building your Android projects, check out the tutorials, and get in touch via the users' mailing list, or IRC.
Finally, as with Jenkins itself, all plugins distributed are open-source, so feel free to contribute!
There is a newer version of the announcement for Jenkins administrators. Please see this blogpost. |
JEP-200 has been integrated into Jenkins weekly builds and (if all goes well) will be a part of the next LTS line. In a nutshell, this change is a security hardening measure to be less permissive about deserializing Java classes defined in the Java Platform or libraries bundled with Jenkins. For several years now, Jenkins has specifically blacklisted certain classes and packages according to known or suspected exploits; now it will reject all classes not explicitly mentioned in a whitelist, or defined in Jenkins core or plugins.
Back up your Jenkins instance prior to upgrade so you have any easy way of rolling back. If you are running any of the plugins listed inPlugins affected by fix for JEP-200, update them after taking the backup but before upgrading Jenkins core.
If you have a way of testing the upgrade in an isolated environment before applying it to production, do so now.
Using backups and a staging server is good advice before any upgrade but especially this one, with a relatively high risk of regression.
To the extent that advance testing of the impact of this change on popular plugins has been completed,
most users (and even plugin developers) should not notice any difference.
If you do encounter a java.lang.SecurityException: Rejected: some.pkg.and.ClassName in the Jenkins UI or logs,
you may have found a case where an unusual plugin, or an unusual usage mode of a common plugin,
violates the existing whitelist.
This will be visible in the Jenkins system log as a message from jenkins.security.ClassFilterImpl like the following:
some.pkg.and.ClassName in file:/var/lib/jenkins/plugins/some-plugin-name/WEB-INF/lib/some-library-1.2.jar might be dangerous, so rejecting; see https://jenkins.io/redirect/class-filter/
where the link would direct you here.
If you find such a case, please report it in the Jenkins issue tracker, under the appropriate plugin component.
Link it to JENKINS-47736 and add the JEP-200 label.
If at all possible, include complete steps to reproduce the problem from scratch.
Jenkins developers will strive to evaluate the reason for the violation and offer a fix in the form of a core and/or plugin update.
For more details and current status, seePlugins affected by fix for JEP-200.
Assuming you see no particular reason to think that the class in question has dangerous deserialization semantics, which is rare, it is possible to work around the problem in your own installation as a temporary expedient. Simply make note of any class name(s) mentioned in such log messages, and run Jenkins with this startup option (details will depend on your installation method):
-Dhudson.remoting.ClassFilter=some.pkg.and.ClassName,some.pkg.and.OtherClassName
As a plugin developer encountering this kind of error,
your first task is to ensure that it is reproducible in a functional (JenkinsRule) test
when running Jenkins 2.102 or newer to reproduce the error.
mvn test -Djenkins.version=2.102 -Denforcer.skip=trueThe above assumes you are using a recent 2.x or 3.x parent Plugin POM. For certain cases you may need to use Plugin Compat Tester (PCT) to run tests against Jenkins core versions newer than your baseline.
Running PCT against the latest Jenkins core:
java -jar pct-cli.jar -reportFile $(pwd)/out/pct-report.xml \
-workDirectory $(pwd)/work -skipTestCache true -mvn $(which mvn) \
-includePlugins ${ARTIFACT_ID} -localCheckoutDir ${YOUR_PLUGIN_REPO}You may need to run tests using an agent (e.g., JenkinsRule.createSlave) or force saves of plugin settings.
For maven plugins you can also specify custom Jenkins versions in Jenkinsfile to run tests against JEP-200:
buildPlugin(jenkinsVersions: [null, '2.102'])(again picking whatever version you need to test against) so that the test is included during CI builds, even while your minimum core baseline predates JEP-200.
If your plugins are built with Gradle, your mileage may vary.
If you discover a compatibility issue in your plugin, you then have several choices for fixing the problem:
Ideally, simplify your code so that the mentioned class is not deserialized via Jenkins Remoting or XStream to begin with:
If the problem occurred when receiving a response from an agent, change your Callable (or FileCallable) to return a plainer type.
If the problem occurred when saving an XML file (such as a config.xml or build.xml), use a plainer type in non-transient fields in your persistable plugin classes.
If the class(es) are defined in the Java Platform or some library bundled in Jenkins core, propose a pull request adding it to core/src/main/resources/jenkins/security/whitelisted-classes.txt in jenkinsci/jenkins.
If the class(es) are defined in a third-party library bundled in your plugin, create a resource file META-INF/hudson.remoting.ClassFilter listing them. (example)
You may also do this for Java or Jenkins core library classes, as a hotfix until your core baseline includes the whitelist entry proposed above.
If the class(es) are defined in a JAR you build and then bundle in your plugin’s *.jpi, add a Jenkins-ClassFilter-Whitelisted: true manifest entry. This whitelists every class in the JAR. (example)
This is a guest post by Alyssa Tong, who runs the Jenkins Area Meetup program and is also responsible for Marketing & Community Programs at CloudBees, Inc. |
Happy 2018! The Jenkins World train is ready to take off once again. As usual, the sign of festivities looming begins with the Call for Papers. Those who attended Jenkins World 2017 know that Jenkins World 2018 is coming back to San Francisco. But what they did not know is that Jenkins World will also be coming to Europe. You read that right, Jenkins World is taking place in two locations in 2018:
Jenkins World USA | San Francisco | September 16 - 19, 2018
Jenkins World Europe | October - date and location TBA
To encourage open collaboration and stimulate discussions that will help advance Jenkins adoption and drive it forward, we invite Jenkins users, developers and industry experts to submit a speaking proposal to Jenkins World San Francisco and or Europe. Submissions for both locations are being accepted now and will close on March 18, 2018 @ 11:59PM Pacific.
Submissions for both Jenkins World USA and Europe are accepted at:
Yes, you can! Once you’ve created an account on the CFP website you will be given the option to make submission(s) to one conference or both conferences.
CFP Opens: January 17, 2018
CFP Closes: March 18, 2018 @ 11:59pm Pacific
CFP Notifications: April
Agenda Announcement: April
Event Dates:
Jenkins World USA | San Francisco | September 16 - 19, 2018
Jenkins World Europe | October - exact date TBA
Recently some UI improvements around the Manage Jenkins page have been introduced. The visual changes are very subtle but behind them, there are interesting benefits.
Some of the goals that we have tried to achieve:
Applying a semantic HTML
Removing the <table> tag usage for implementing layouts and content structures. Read this article if you want to know reasons and/or arguments.
Small re-styling focused on spacing, margins, composition, etc..
Accessibility
In order to provide a quick overview of the visual changes, let’s take a look at these screenshots.
Information about how this change can affect the current implementations of Administrative Monitors can be found in the following section
Let’s use a real example for showing how this proposal works.
This is the original UI implementation of HudsonHomeDiskUsageMonitor.java:
<?jelly escape-by-default='true'?><j:jellyxmlns:j="jelly:core"xmlns:st="jelly:stapler"xmlns:d="jelly:define"xmlns:l="/lib/layout"xmlns:t="/lib/hudson"xmlns:f="/lib/form"><divclass="warning"><formmethod="post"action="${rootURL}/${it.url}/act"name="${it.id}"><divstyle="float:right"><f:submitname="yes"value="${%Tell me more}"/><f:submitname="no"value="${%Dismiss}"/></div>
${%blurb(app.rootDir)}</form></div></j:jelly>And this is the proposed change:
<?jelly escape-by-default='true'?><j:jellyxmlns:j="jelly:core"xmlns:st="jelly:stapler"xmlns:d="jelly:define"xmlns:l="/lib/layout"xmlns:t="/lib/hudson"xmlns:f="/lib/form"><divclass="alert alert-warning"><formmethod="post"action="${rootURL}/${it.url}/act"name="${it.id}"><f:submitname="yes"value="${%Tell me more}"/><f:submitname="no"value="${%Dismiss}"/></form>
${%blurb(app.rootDir)}</div></j:jelly>Some highlights:
No more ad hoc UI compositions
No more custom CSS classes when Jenkins project is already using Bootstrap for many different things
Based on Bootstrap Alert
All administrative monitors defined in Jenkins core have been adapted as part of this proposal.
No changes are really needed, but we do recommend you to adapt your plugins to this proposal so Jenkins users have a better user experience.
Taking into account that you want to keep backward compatibility, you will need some changes.
In your implementation of Administrative Monitor, add this helper method:
/**
* This method can be removed when the baseline is updated to 2.103
*
* @return If this version of the plugin is running on a Jenkins version where JENKINS-43786 is included.
*/@Restricted(DoNotUse.class)publicboolean isTheNewDesignAvailable() {if (Jenkins.getVersion().isNewerThan(new VersionNumber("2.103"))) {returntrue;
}returnfalse;
}In your view (a.k.a. Jelly file or Groovy file):
<?jelly escape-by-default='true'?><j:jellyxmlns:j="jelly:core"><j:iftest="${!it.isTheNewDesignAvailable}"><divclass="warning"><p>SSH Host Key Verifiers are not configured for all SSH slaves on this Jenkins instance. This could leave these slaves open to man-in-the-middle attacks. <ahref="${rootURL}/computer/">Update your slave configuration</a> to resolve this.</p></div></j:if><j:iftest="${it.isTheNewDesignAvailable}"><divclass="alert alert-warning">
SSH Host Key Verifiers are not configured for all SSH slaves on this Jenkins instance. This could leave these slaves open to man-in-the-middle attacks. <ahref="${rootURL}/computer/">Update your slave configuration</a> to resolve this.</div></j:if></j:jelly>If you don’t want to keep a strict backward compatibility, the impact is minimal. In fact, you can see an example on GitHub Plugin.
Some helpful references:
JIRA issue where the proposal was tracked
Pull Request with the change in Jenkins core. You can find several screenshots
Pull Request for adapting SSH Slave Plugin
Do not hesitate to ping me if you decide to adapt your Administrative Monitors.
On the first weekend in February, numerous free and open source developers from around the world will travel to Brussels, Belgium, for arguably the largest event of its kind:FOSDEM. Among the thousands of hackers in attendance will be a number of Jenkins contributors.
On the Monday after FOSDEM,you are invited to join a group of those contributors for a full day of hacking on Jenkins. Folks of all experience levels are welcome; there will be sessions for everyone from seasoned hackers to new contributors.
The Hackfest will start at 9:30am on Monday with general introductions and gathering of potential topics/projects. Bring suggestions for topics that interest you, or just come and choose from the topics others suggest. There will be plenty of topics from which to choose. All the topic suggestions will all be added to a backlog and we will identify and cluster around popular topics. Then we’ll divide into smaller groups and work on individual topics in timeboxed sessions.
Meals, snacks, and beverages will be provided throughout the day, wrapping up with dinner around 5pm.
Hackfests like this one are a great opportunity for contributors of all levels to get invovled, learn from each other, and work together on interesting and high impact areas of the project.
Some long-time contributors already know what areas they’ll work on and are looking for people interested in joining them. Mark Waite (maintainer of the Jenkins Git and Git Client plugins) and Christian Halstrick (SAP) will be spending the day improving the way Git client plugin uses JGit. R. Tyler Croy (Jenkins community concierge) and Olivier Vernin (Jenkins infrastructure engineer) will work on infrastructure improvements.
Others contributors, such as Jesse Glick and Andrew Bayer (recipients of the "A Small Matter of Programming" award), will arrive without a set plan. They will, of course, have some topics to propose, so you might get a chance to work with them. Or if you have an area you’d like to work on, they and many other experts will be on hand for discussion and code review.
This is also a great opportunity for new contributors to join the project. Baptiste Mathus, long time contributor and all-around nice guy, will host a "New Contributor Hackergarten" covering the basics of contributing to Jenkins and submitting fixes via GitHub Pull requests. Even those with minimal coding experience can contribute by improving documentation and making typo fixes via this same process.
More than anything else, Hackfests like this are great fun. No matter what your level of exerience, there will be plenty to do and great people with whom to do it. Reserve a space byjoining the meetup here. Then bring your own laptop and passion for improving Jenkins.
Date: Monday, February 5, 2018
Time: 9:30 AM to 5:00 PM
Location: BeCentral sprl/bvba Cantersteen 12 1000 Brussel Belgium Room: Studio C (1st floor)
Meals, snacks, and beverages will be provided. Bring your own computer.
| Ask for "Jenkins" at the front desk if you get lost. |
Multiple Jenkins plugins received updates today that fix several security vulnerabilities.
For an overview of these security fixes, see the security advisory.
Subscribe to the jenkinsci-advisories mailing list to receive important future notifications related to Jenkins security.
We just released security updates to Jenkins, versions 2.107 and 2.89.4, that fix multiple security vulnerabilities.
For an overview of what was fixed, see the security advisory. For an overview on the possible impact of these changes on upgrading Jenkins LTS, see our LTS upgrade guide.
| While the severity score works out as medium for all the vulnerabilities, we strongly recommend that anyone operating publicly accessible Jenkins instances update as soon as possible, as their secrets on disk might be at risk by SECURITY-705. |
Subscribe to the jenkinsci-advisories mailing list to receive important notifications related to Jenkins security.
We are happy to announce that Jenkins project has been accepted toGoogle Summer of Code 2018. This year we invite students and mentors to join the Jenkins community and work together on various initiatives: core, plugins, development tools and infrastructure.
Our mentors have already created some project ideas. For example, you are welcome to work on the new Configuration-as-Code initiative or to help creating standard API for Code Coverage plugins. If you like test automation, there is a proposal toJenkins Acceptance Test Harness. Over the next weeks we plan to extend this list by new even more project ideas.
All information about the Jenkins GSoC is available on its subproject page.
See Information for students for application guidelines.
First step is to join discussions in the mailing lists in order to introduce yourself, establish connections with the community and potential mentors. The application period starts on March 12 and ends on March 27, but don’t let it misguide you! Use time before application to discuss project ideas/proposals with mentors and to process their feedback. To create a better proposal, we also recommend to study Jenkins and to do some contributions in the area of your project proposal.
Not satisfied by the current project ideas? You can propose your own idea in the developer mailing list.
It’s not! If you are passionate about open-source and Jenkins, we invite you to join the mentors team. You can either propose a new project idea or join an existing one. See Call for Mentors and Information for mentors for details.
This year mentorship does NOT require strong expertise in Jenkins development. The objective is to guide students and to get involved into the Jenkins community. GSoC org admins will help to find advisers if special expertise is required.
Mar 05 - deadline for new GSoC project idea proposals
Mar 12 - student application period starts
Mar 27 - deadline for student applications
Apr 23 - accepted projects announced, community bonding starts
May 14 - coding period starts
Aug 06 - end of the coding period
See the GSoC Timeline for more info. In the Jenkins project we will also organize special events during and after GSoC (e.g. at Jenkins world).
P.S: I am going to create a special GSoC 2018 edition of swags for mentors and students. Do not miss them ;)
This is a guest post by Sam Van Oort, Software Engineer at CloudBees, and contributor to the Jenkins project, and maintainer of the Pipeline Plugins. |
Since it launched, Pipeline has had a bit of a Dr. Jekyll and Mr. Hyde performance problem. In certain circumstances, Pipeline can turn from a mild-mannered CI/CD assistant into a monster. It will happily eat storage read/write capacity like popcorn without caring about the other concerns of our friendly butler. When combined with other additional factors, this can result in real-world stability problems. For example, combining slow storage with a spike in running Pipelines has brought down production Jenkins at more than one organization. Similarly, users see issues if a busy master gets hit with an extra source of stress; past culprits have been heavy automated (ab)use of Jenkins APIs, now-solved user lookup bugs, backup jobs, and plugins run crazy that load excessive numbers of builds. Symptoms ranged from visible slowdowns in the UI to unresponsive jobs and "hung" masters.
Now I’m not saying this to scare people or to criticize the technology we’ve built. Implementing Pipeline scalability best practices coupled with SSD storage keeps Jenkins in a happy place. We just need context on the weaknesses to see why it’s important to address them.
Today we’re announcing the first major results of "Project Cheetah", our long-running effort to address these challenges and improve Pipeline scalability. More broadly, Cheetah aims to help in 3 places:
Small-scale containers: Pipeline needs to run leanly in resource-constrained containers, to enable easy scale-out without consuming excessive resources on shared container hosts.
Enterprise systems: Pipeline needs to effectively serve high-scale Jenkins instances that are central to many large companies.
General case: run Pipelines a bit more quickly on average, and allow users to get much-stronger performance in worst-case scenarios.
These changes are implemented across many of the Pipeline plugins.
Project Cheetah offers several things, but the most important is Durability Settings for all Pipelines, and especially the Performance-Optimized setting. This setting avoids several potentially unexpected performance "surprises" that may strike users. In the general case, it greatly reduces the disk IO needs for Pipeline. How much? Below is a graph of storage utilization with legacy Pipeline versions (think early 2017) and with the latest version using the Performance-Optimized mode. These are tested on an AWS instance backed by an EBS volume provisioned with 300 IOPs.
Before and After:
As you can see, storage utilization goes down by a lot. While the exact number will vary, across the benchmark testcases this results in Pipeline throughput of 2x to 6x the previous before becoming IO-bound. This also increases stability of Jenkins masters because they will tolerate unexpected load.
This comes with a major drop in CPU IOWait as well:
And of course the rate at which data is written to disk and number of writes/s is also reduced:
For enterprise users, timing stats often show 10-20% of normal builds is serializing the Program and writing the record of steps run ("FlowNodes") - the performance optimized durability setting will cut this to almost nothing (for standard pipelines, 1/100 or less) - so builds will complete faster, especially complex ones.
Please see the Pipeline Scalability documentation for deeper information on the new Durability Settings, how to use them, and which plugin versions are required to gain these features.
Also, users may see a reduction in hung Pipelines because new test utilities made it possible to identify and correct a variety of bugs.
There are 3 ways to configure the durability setting:
Under "Manage Jenkins" > "Configure System", labelled "Pipeline Speed/Durability Settings". You can override these with the more specific settings below.
This is one of the job properties located at the top of the job configuration, labelled "Custom Pipeline Speed/Durability Level." This overrides the global setting. Or, use a "properties" step - the setting will apply to the NEXT run after the step is executed (same result).
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
options {
durabilityHint('PERFORMANCE_OPTIMIZED')
}
}Under the SCM you can configure a custom Branch Property Strategy and add a property for Custom Pipeline Speed/Durability Level. This overrides the global Durability Setting and will apply to each branch at the next run. You can also use a "properties" step to override the setting, but remember that you may have to run the step again to undo this.
Durability settings will take effect with the next applicable Pipeline run, not immediately. The setting will be displayed in the log.
There is a slight durability trade-off for using the Performance-Optimized mode — the appropriate section of the Pipeline Scalability documentation has the specifics. For most uses we do not expect this to be important, but there are a few specific cases where users may wish to use a slower/higher-durability setting. The Best Practices are documented.
We recommend using Performance-Optimized by default, but because it does represent a slight behavioral change the initial "Cheetah" plugin releases defaults to maintain previous behavior. We expect to switch this default in the future with appropriate notice once people have a chance to get used to the new settings.
Yes, if your Jenkins instance uses NFS, magnetic storage, runs many Pipelines at once, or shows high iowait (above 5%)
Yes, if you are running Pipelines with many steps (more than several hundred).
Yes, if your Pipeline stores large files or complex data to variables in the script, keeps that variable in scope for future use, and then runs steps. This sounds oddly specific but happens more than you’d expect.
For example: readFile step with a large XML/JSON file, or using configuration information from parsing such a file with One of the Utility Steps.
Another common pattern is a "summary" object containing data from many branches (logs, results, or statistics). Often this is visible because you’ll be adding to it often via an add/append or Map.put() operations.
Large arrays of data or Maps of configuration information are another common example of this situation.
No, if your Pipelines spend almost all their time waiting for a few shell/batch steps to finish. This ISN’T a magic "go fast" button for everything!
No, if Pipelines are writing massive amounts of data to logs (logging is unchanged).
No, if you are not using Pipelines, or your system is loaded down by other factors.
No, if you don’t enable higher-performance modes for pipelines. See above for how!
Users can now set an optional job property so that individual Pipelines fail cleanly rather than resuming upon restarting the master. This is useful for niche cases where some Pipelines are considered disposable and users would value a clean restart over Pipeline durability.
We’ve reduced classloading and reflection quite significantly, which improves scaling and reduces CPU use:
Script Security (as of version 1.41) has gotten optimizations to reduce the performance overhead of Sandbox mode and eliminate lock contention so Pipeline multithreads better.
Pipeline Step data uses up less space on disk (regardless of the durability setting) - this should be 30% smaller. Assume it’s a few MB per 1000 steps - but for every build after the change.
Even in the low-performance/high-durability modes, some redundant writes have been removed, which decreases the number of writes by 10-20%.
That’s probably material for another blog post or Jenkins World talk.
The short answer is: first we built a tool to simulate a full production environment and provide detailed metrics collection at scale. Then we profiled Jenkins to identify bottlenecks and attacked them. Rinse and repeat.
The next big change, which I’m calling Cheetah Part 2 is to address Pipeline’s logging. For every Step run, Pipeline writes one or more small log files. These log files are then copied into the build log content, but are retained to make it possible to easily fetch logs for each step.
This copying process means every log line is written twice, greatly reducing performance, and writing to many small files is orders of magnitude slower than appending to one big log file.
We’re going to remove this duplication and data fragmentation and use a more efficient mechanism to find per-step logs. This should further improve the ability to run Pipelines on NFS mounts and hard-drive-backed storage, and should significantly improve performance at scale.
Besides this, there’s a variety of different tactical improvements to improve scaling behavior and reduce resource needs.
The Project Cheetah work doesn’t free users to completely ignorePipeline scaling best practices and previous suggestions. Nor does it eliminate the need for efficient GC settings. But this and other enhancements from the last year can significantly improve the storage situation for most users and reduce the penalties for worst-case behaviors. When you add all the pieces together, the result is a faster, leaner, more reliable Pipeline experience.
You’ve marked your calendar to alert you weeks in advance of the CFP deadline. You’ve spent your nights and weekends to skillfully craft your abstract and you are convinced this is THE one. You confidently clicked the submit button only to find out weeks later you’ve received an automated declined email. On top of feeling disappointed, you probably wondered why your proposal was turned down.
As Jenkins World CFP is still open, we hope to demystify the selection process by offering a few tips to help increase the chance of your proposal getting accepted.
There’s only a few seconds to make an impression with your proposal. Your title and abstract should be succinct and attention grabbing. Think about what makes your Jenkins proposal exceptional over others. What value will it bring to attendees?
Jenkins World audiences want to learn and adopt the newest development practices, process, languages and frameworks. They are highly technical and are interested in deep technical talks that are original and offers valuable information.
Share your unique Jenkins project experiences, challenges, strategies, lessons learned, and outcome. What can you share with your audience that will facilitate knowledge transfer and development of new and innovative techniques?
Consider how to make the topic more broadly applicable to the attendees, such as with a hands-on demo explaining the concept. By showcasing innovative methods that draw out relevant and compelling knowledge to the audience, everybody is likely to more thoroughly absord the content of the talk. Also, who doesn’t love a cool demo?
Jenkins is used tons of different ways. Sharing novel approaches, tips, or tricks for increased efficiency and proficiency with Jenkins is almost always well received!
CFP Closes: March 18, 2018 @ 11:59pm Pacific
CFP Notifications: April
Agenda Announcement: April
Event Dates:
Jenkins World USA | San Francisco | September 16 - 19, 2018
Jenkins World Europe | Nice, France | October 23 - 25, 2018
Register for Jenkins World
2018 with the code |
Good Luck!
Over the last year, several efforts were done on jenkins.io likesecurity advisories or documentation and I wanted to understand the impact it had on its traffic.
I had a look to the Google Analytics account used for jenkins.io and it was interesting to discover which browsers are used by Jenkins visitors and how this compares with other websites. So I decided to analyze one year of data from January 2017 to January 2018. Then I selectedstatcounter as an external data source in order to compare results from jenkins.io.
First, let’s talk about numbers:
During that period, 3,496,245 users across the world visited this website.
This is a growth of 52.69% visitors compared to the year before.
92.28% of them used a desktop, 6.63% were on mobile and only 1.10% on a tablet.
| Browser | Percentage |
|---|---|
Chrome | 69.82% |
Firefox | 14.75% |
Safari | 6.44% |
IE | 5.84% |
Edge | 1.59% |
We clearly see that 91% of Jenkins.io visitors only use three browsers. Chrome is by far the leader followed by Firefox and Safari.
Obviously those numbers taken alone don’t mean anything, so let’s try to put them in perspective with another data source.
Netscape 4.8 was still used by 15 visitors over the year.
6 visitors used their Nintendo DS.
Let’s now compare our previous results with the same time period from statcounter who argues to collect data from 2million websites. Statcounter allow us to display browsers stats based on 4 different categories, All platform, Desktop, Tablet or Mobile. + For this comparison, I am interested by All platform and of course Desktop as 92.28% of Jenkins.io visitors use a desktop.
| Browser | Percentage |
|---|---|
Chrome | 54.13% |
Safari | 14.50% |
UC Browser | 8.25% |
Firefox | 6.15% |
IE | 3.89% |
Excepted Chrome who still leads the ranking with "only" 54%, all the others actors are totally shuffled. Safari moved to the 2nd place with 14.50% UC Browser appeared in the top 3 with 8.25% where only 0.10% of Jenkins.io visitors were using UC browser. Firefox moved to the 4th places with only 6.15%. It’s interesting how this "All platform" browser market share from statcounter doesn’t reflect Jenkins.io visitors' habits. (Source)
Now at a first glance, results look more similar to the Jenkins.io visitors; excepted for Chrome and Firefox which shed some percentages in favor of Internet Explorer and Edge. This promotes IE to the 3rd place with 8.86% of usage, and downgrade Safari to the 4th place with 6,44%. Compared to Jenkins.io results, Edge is still at the 5th position. It’s very interesting to see how this ranking is so different from the "All platform" one but follows the same pattern coming from Jenkins.io visitors. This highlights how browser choices are strongly influenced by the platform used and contrary to a general trend, Jenkins.io visitors remain desktop users. This absence of mobile users probably explains why some browsers are so under represented within Jenkins visitors. (Source)
| Browser | Usage |
|---|---|
Chrome | 63.59% |
Firefox | 13.75% |
IE | 8.86% |
Safari | 5.50% |
Edge | 4.35% |
These observations should be carefully interpreted as it may be overestimated or underestimated (depending on various factors) and doesn’t take into consideration local specificities.
Jenkins.io visitors are a majority of desktop users. They are aligned with the world trends when we talk about desktop browsers however only a minority of them come from a mobile. This is probably because jenkins.io is not (yet) mobile friendly and obsiously this would be a nice improvement to have.
All contributions are welcomed and especially for mobile user experience.
On behalf of the Jenkins Events Team, I would like to invite you to the “Jenkins & Java 10 Online Hackathon” which will take place from June 18th to 22nd. We will be working together on Jenkins core and plugins in order to find and fix compatibility issues, share experiences and have some fun. Everybody is welcome to join, independently of their Jenkins experience and amount of time they have available.
If you are interested in participating in the hackathon, please sign-up inthis form.
Java 9 has recently been end-of-lifed, Java 10 is in GA, and Java 11 is in early beta. Jenkins project currently requires Java 8 to run reliably, and there are some known compatibility issues with higher Java versions.
During the Jenkins World 2017 Hackathon,Mark Waite andBaptiste Mathus spent some time exploring Java 9 compatibility in Jenkins. We are currently tracking compatibility issues in theJENKINS-40689 EPIC, but there are likely many unknown issues in Jenkins core, plugins and in libraries we use in the project. We would like to continue their effort and work on Java 10+ support.
As I have said above, the goals are to explore/fix compatibility issues, share experiences and have fun. We DO NOT plan to make Jenkins fully compatible with Java 10+ during the hackathon, but we will try to integrate fixes and make them available.
Since the announcement of the Hackathon in the mailing list, we have got a number of registrations from contributors working on several project areas. We will split our work to several areas:
Jenkins core and Remoting
Pipeline Engine
Plugins (e.g. Git plugin or any plugin you want to work on)
Exploratory testing for Java 10 and beyond
In order to organize the effort, we have created ajava10_hackathon label in Jenkins JIRA. If you are interested in particular tasks, please assign them to yourself and add the label.
Currently the event is in the planning stage. We will be using the Developer mailing list for synchronization before the event.
What will we have?
Communications in #jenkins-hackhouse IRC and in theJenkins Gitter channel
Daily recorded sync-up calls in Hangouts
Knowledge transfer sessions during the event
We also want to prepare some special swag for active participants. If you have reached this part of the blogpost, you have probably seen the logo ;)