Quantcast
Channel: Jenkins Blog
Viewing all 1088 articles
Browse latest View live

Jenkins Election 2021

$
0
0

Jenkins Needs You transparent

Dear all,

Time flies and the Jenkins elections period is here.

This year, two board seats and all officer positions are up for election. Thanks, Oleg Nenashev and Ullrich Hafner who led the Jenkins project as board members for the last two years. Thanks, Tim Jacomb, Daniel Beck, Mark Waite for your dedication as officers over the past year.

We already had two successful editions in a row. I want us to continue on that path. This is a tremendous opportunity for community members to influence the direction of the project for the next two years. To make this year’s election even better, we slightly modified the process by leveraging our new community platform aka community.jenkins.io.

To participate in the election, we ask every Jenkins community member to have an account on community.jenkins.io. You can either reuse your Github account or create a new discourse account specific to community.jenkins.io. The second requirement is to be able to showcase at least one contribution done before the first of September 2021. As mentioned on jenkins.io.io/participate, they are many different ways to contribute to Jenkins and for many of them, it’s very difficult to measure. Therefore we’ll trust participants and will not require that they provide evidence of contribution as part of their voter registration. We reserve the right to ban the specific account from the election process if we identify abuse. The election works in three stages:

  1. Identify voters and nominees

  2. Voting period

  3. Announce results

Voters

To invite participants to vote, we need a list of email’s addresses that we would share with the Condorcet Internet Voting Service. Therefore we ask every community member who matches the requirements to join the group election-voter on community.jenkins.io . The group will be open for joining during the registration period after we’ll close registration during the voting period. We’ll use emails from the “election-voter” group members.

Nominees

During the same period, we invite every community member to nominate candidates by sending a message to the group election-committee mentioning the position and the motivation. On the 31 of October, the nomination period will end. We’ll notify all the nominees and get confirmation that they are interested in running as a candidate. The list of candidates will be announced on the 7th of November.

Everybody can nominate candidates.

This year we are looking for nominees for the following positions:

More information about the different roles can be found on jenkins.io/project/team-leads.

Election

On the 7th of November, once voters and candidates are identified, we’ll invite everybody by email to vote using civs.cs.cornell.edu. At this stage of the election, nobody will be allowed to register. Voting deadline is the 30th of November.

Result

As soon as we have the election results, we’ll publish them. Elected members will begin their official roles on the 3rd of December 2021.

Key Dates

  • Sep 20: Nomination and voter registration begin

  • Oct 31: Nomination deadline

  • Nov 07: Candidates announced, Registration deadline, voting start

  • Nov 30: Voting deadline

  • Dec 03: Results announced

Key Information:

Cheers,


register button


Join Jenkins at DevOps World 2021

$
0
0

DevOps World has been the largest gathering for Jenkins for many years. In keeping with tradition, many Jenkins presentations and sessions are planned for this year’s event.

devops world 2021

Join us for DevOps World on September 28 - 30, 2021. The event is virtual, free to attend and will include the following Jenkins activities:

Jenkins workshops

  • Contributing to Open Source

  • Securing Jenkins Pipeline with CyberArk Conjur Secrets Manager

See the conference workshop list for more information about workshops.

Breakout sessions

See the full agenda for more Jenkins sessions.

Birds of a feather

These are 30 minute networking sessions. Topics will be on security and pipeline. Discussions are led by Wadeck Follonier, Daniel Beck, Joost van der Griendt, and Mark Waite.

Jenkins contributor summit

A Jenkins Contributor Summit will be held October 2, 2021 at 7:00 AM UTC.

The planning discussion is taking place at community.jenkins.io. We welcome topic suggestions or you can volunteer to present a topic about which you are passionate. Join in on the discussion. New and veteran contributors are welcome!

Virtual expo hall

Be sure to stop by the Jenkins booth for project update content or to chat with one of the Jenkins maintainers.

Special thanks to review committee

Lastly, special THANKS to the DevOps World review committee. We are grateful for their contributions to review, score and provide feedback for paper submissions.

Looking forward to seeing you there!

New eBook: Fortune 500 Developers and Engineers Turn to Jenkins for Real-World Results

$
0
0

Jenkins User Success Stories in the Fortune 500

If you’ve been following JenkinsIsTheWay.io, you’ve read some fantastic stories from the Jenkins user community about the great stuff they are building with Jenkins. With over 200,000 installations to date, Jenkins remains the most widely used open-source automation server. And story after story, we hear what a critical role Jenkins plays in building robust, secure CI/CD pipelines.

So it comes as no surprise that in many of the back (and remote) offices of Fortune 500 companies, developers are turning to Jenkins to help make their lives easier with automation while also giving their engineers more time to innovate. With this in mind, I invite you to read the latest ebook focused on the behind-the-scenes development activities underway in large-scale enterprises.

Jenkins led

Learn how companies like IBM continue to innovate their software prowess while confidently relying on their custom-built CI/CD pipelines. You’ll also read how Jenkins became the ultimate collaboration tool for thousands of Apple developers. And we don’t just shine the spotlight on tech companies. In this ebook, Jenkins users span multiple industries across the enterprise.

You’ll read how Jenkins made it possible to standardize multidisciplinary team procedures so Roche engineers can create innovative healthcare applications with confidence. We also dive into how Telstra’s software team was able to automate the build cycle - across 100,000 microservices - to accelerate the creation of world-class communication tools. And how Sainsbury’s development team used Jenkins as the way to "bring a retail giant into the 21st century".

Results inspired

No time to dive into this Fortune 500 ebook? I thought it’s worth highlighting the real-world results experienced by enterprise developers and engineers who have turned to awesome plugins to help build, deploy and automate their software solutions. Here’s what they had to say in their own words!

Software acceleration

  • Build times are much faster with the new node mechanism

  • Shared build pipelines are consistent and evolve faster

  • Faster deployment times - from 5 days to several minutes

  • Deploy multiple server patches 30x faster than normal processes

  • Reduce release time from 7 to 4 days

Simpler, smarter processes

  • One-stop-shop for building, deploying, monitoring, testing and even self-managing

  • Easy onboarding for new applications

  • Credential management has gotten much simpler and stricter

  • Made setting up CI/CD really easy

  • Provides the visibility needed to track the deployment process

Loved and relied on by developers

  • Ultimate collaboration tool for thousands of developers

  • 100% confidence in a consistent and repeatable pipeline

  • Keeps the DevOps team in the loop

  • Jenkins-as-code has freed teams up to experiment more

  • Teams are more self-empowered to provision and support their own builds

One thing to remember is that since Jenkins is a free open source solution, it also means savings across the enterprise. This is highlighted in several of our user stories in this ebook. You’ll discover how peers have "decreased build server costs" and have mentioned "cost-cutting" as a top Jenkins benefit.

Share your story

Whether working for a large corporation or an emerging tech startup, we relish hearing your experiences and the results you get with a Jenkins assist. When you’re ready to tell your story, we’re prepared to help you share it. Fill out our short questionnaire, and we’ll send you our Jenkins Is The Way T-shirt as a thank you once it’s published!

Jenkins Health Advisor by CloudBees Tool Makes Life Easier for Jenkins Administrators

$
0
0

Jenkins Health Advisor by CloudBees logo

There are many ways to set up your Jenkins environment, and depending on the configuration you choose, there are different best practices and options to optimize your environment. In this blog, I’m going to focus on Jenkins Health Advisor by CloudBees as a way to fine-tune your environment. It’s a free tool that can help administrators understand and manage their Jenkins controller. If you’re a CloudBees customer, the tool automatically comes with CloudBees CI. However, it’s also available as a free open source tool to anyone who uses Jenkins. The Jenkins Health Advisor tool can make your life easier, because it can arm you with the information you need to keep your Jenkins environment running smoothly.

A Bit of Background

The CloudBees support team originally created the tool as a way to help customers troubleshoot Jenkins issues. With the tool, our support engineers could gather information from a customer’s Jenkins controller about the configuration of the controller and agents, the operating system, stats from web requests, and the like. Our tech support teams used this data to help customers pinpoint problems, such as security vulnerabilities, performance problems, and plugin version issues. Very quickly, our support tooling team saw the bigger-picture benefits of the diagnostic tool as an opportunity for people to proactively manage their controller. With that bit of background, let’s dive into the Jenkins Health Advisor tool so you understand how it can help you.

The Problem — Lack of Visibility into Controller Environment

Because of the open-source nature of Jenkins and the vast array of plugins that you can deploy in your Jenkins installation, downstream code changes to plugins and corresponding dependencies can inadvertently impact your environment, which slows productivity, causes confusion, and impacts the quality of your software delivery. When problems arise, Jenkins administrators need to quickly pinpoint the root cause of an issue, and that can be quite a challenge.

The Solution — Jenkins Health Advisor by CloudBees

When an issue arises, you need razor sharp insight to help you quickly sift through lines upon lines of data about your Jenkins controller and your plugins to identify the problem. And, that’s exactly what Jenkins Health Advisor does. It gives you specific information about potential problems in your environment so you can resolve issues as quickly as possible.

When you first install the Jenkins Health Advisor tool in your environment, you’ll receive a report that lists everything it detects in your system. You’ll then receive report emails only when something changes that could impact your environment or when the tool identifies an issue that could be problematic. If there are no issues in your environment, you don’t receive an email. It’s really that simple.

The Power is in the Insight … and the CloudBees Support

Ok, so let’s explain how Jenkins Health Advisor uses data to help you optimize your environment. The tool actually generates a support bundle every 24 hours. We don’t want to bog down your email inbox with redundant reports emails, so we don’t send every report to you—only the reports that indicate an issue with your environment. However, CloudBees receives every support bundle from every user. We are constantly monitoring all of this active Jenkins controller data with external Jenkins and open source data about known issues, plugin updates, security vulnerabilities, etc. If the Jenkins Health Advisor tool identifies an issue that could impact your system, you’ll receive an email so you can proactively address the problem. At the same time, CloudBees engineering teams are continually working to enhance the detection capabilities of the Jenkins Health Advisor tool, so you can work as proactively as possible to manage your environment.

The emails you receive identify potential problems, and they also include supporting information to help you resolve issues, with links to solutions and recommended resolutions as well as articles to understand the problem.

Helpful Tips to Gain Value from Jenkins Health Advisor

  • Improve Troubleshooting

    If you need to troubleshoot a particular issue, you can manually generate a support bundle to give you point-in-time information on your environment. You can filter the support bundle data on different system parameters, like the build queue, dump agent export tables, and garbage collection logs, so you get the specific information you need.

  • Generate Anonymized System Data

    At any time, you can change the settings on your tool to anonymize the data in your support bundles. You may want to do this if you don’t want to share sensitive project data with CloudBees. Our support and engineering teams can still gain valuable insight from your generic system data. This is also a helpful feature if you need to share system data with a partner or vendor, and you don’t want to share project or personnel data.

  • Jenkins Health Advisor Tool Updates and Support

    As we mentioned above, the CloudBees support tooling team is constantly working to enhance the tool. To ensure it’s always as current as possible, we release updates to the tool every two weeks. Usually these updates won’t impact your Jenkins environment. However, if there are changes to the tool that might affect your system, you’ll receive a notification email so there are no surprises. And, if you need help with the Jenkins Health Advisor tool, our support engineers are available to answer your questions.

Start Using Jenkins Health Advisor Today

Given the vast Jenkins community, it’s impossible to know everything that may impact your environment, even if you look at your control panel every day and scour open source forums on a regular basis to stay on top of new issues and vulnerabilities. The Jenkins Health Advisor tool is designed to streamline the work effort of your daily routine by automatically telling you when there’s an issue that may impact your Jenkins environment. With the proactive Jenkins Health Advisor notifications, you can spend your time on more strategic tasks.

Congratulations to all Jenkins and CDF Google Summer of Code 2021 participants!

$
0
0

Jenkins GSoC

Congratulations to all Google Summer of Code (GSoC) 2021 students! On behalf of the Jenkins org team, we would like to thank all participants: students, mentors, applicants, and dozens of other contributors who participated in GSoC this year.

In 2021, the Jenkins project participated in GSoC as part of the Continuous Delivery Foundation’s GSoC mentor organisation. Within the CDF GSoC mentor organisation, we had six students working on projects: five projects focused on Jenkins and one project focused on Spinnaker. In GSoC, we focus on projects that solve problems important to end users and community members. This year’s GSoC projects delivered highly anticipated new features for Jenkins and Spinnaker.

Google Summer of Code has been a successful and positive experience for students due to the active participation of the Jenkins community and the wider Continuous Delivery Foundation community.

🎉 All of the CDF GSoC students have successfully completed their projects! 🎉

This is the second year in a row that all Jenkins GSoC students have reached the final evaluation and successfully passed! This has been an extremely challenging year, and the amount of work and dedication that the students and their mentoring teams have put into GSoC has been phenomenal. Jenkins, Spinnaker, and the CDF are incredibly grateful to everyone who has contributed to GSoC 2021!

CDF GSoC

☀️ GSoC Students and their Projects

Please see the individual project pages for more details on the projects and work undertaken. You can view student presentations during mid-term demos and final demos and students have written numerous blog posts about their work.

Shruti Chaturvedi - CloudEvents Plugin for Jenkins

Shruti Chaturvedi

Shruti is an undergrad student of Computer Science at Kalamazoo College. She is developing a CloudEvents integration for Jenkins, allowing other CloudEvents-compliant CI/CD tools to communicate easily. Shruti is also the Founding Engineer of a California-based startup, MeetKlara, where she is building serverless solutions and advocating for developing CI/CD pipelines using open-source tools.

Harshit Chopra - Git credentials binding for sh, bat, and powershell

Harshit Chopra

Harshit Chopra is a recent graduate and is currently working on a Jenkins project which brings the authentication support for cli git commands in a pipeline job and freestyle project.

Git credentials binding for sh, bat, and powershell

Akihiro Kiuchi - Jenkins Remoting Monitoring

Akihiro Kiuchi

Akihiro is a student in the Department of information and communication engineering at the University of Tokyo. He is improving the monitoring experience of Jenkins Remoting during Google Summer of Code 2021.

  • Affiliation: The University of Tokyo and Jenkins project

  • GitHub: Aki-7

Jenkins Remoting Monitoring with OpenTelemetry

Daniel Ko - try.spinnaker.io

Daniel Ko

Daniel is studying computer science at the University of Wisconsin - Madison. He is developing a public Spinnaker sandbox environment for Google Summer of Code 2021.

  • Affiliation: University of Wisconsin - Madison and Spinnaker project

  • GitHub: ko28

  • LinkedIn: Daniel Ko

try.spinnaker.io: Explore Spinnaker in a Sandbox Environment!

Pulkit Sharma - Security Validator for Jenkins Kubernetes Operator

Pulkit Sharma

Pulkit is a student at Indian Institute of Technology,BHU,Varanasi. He is working on a GSoC Project under Jenkins where he aims to add a security validator to the Jenkins Kubernetes Operator.

  • Affiliation: Indian Institute of Technology, BHU and Jenkins Project.

  • GitHub: sharmapulkit04

Security Validator for Jenkins Kubernetes Operator

Aditya Srivastava - Conventional Commits Plugin for Jenkins

Aditya Srivastava

Aditya is a curiosity driven individual striving to find ingenious solutions to real-world problems. He is an open-source enthusiast and a lifelong learner. Aditya is also the Co-Founder and Maintainer of an Open Source Organization - Auto-DL, where he’s leading the development of a Deep Learning Platform as a Service application.

Upcoming Events, September 28-30: DevOps World!

This year CloudBees, one of the Jenkins corporate sponsors, has invited all students to participate in the DevOps World virtual conference on September 28-30. GSoC students will present lighting talks about their projects, attended other conference talks, and join the Continuous Delivery Foundation booth which represents CDF projects at the conference. We look forward to GSoC students' lightning talks during DevOps World!

Swag

All Google Summer of Code students and mentors receive swag from Google. In addition, this year, CloudBees has sponsored swag for the most active GSoC participants: all students, mentors, and many other contributors who participated and helped the projects to succeed. This is the forth year when the Jenkins organization sends extra GSoC swag. In the previous years swag logistics was one of the more challenging tasks for org admins during GSoC, and we highly appreciate that the Continuous Delivery Foundation will handle sending out the additional swag.

Jenkins Election 2021

$
0
0

Voter registration is now open for the 2021 Jenkins project elections. Two members of the governing board are up for election. Five officers are up for election.

How Do I Register to Vote?

register button

Click the "Register Here" button above or open https://community.jenkins.io/g/election-voter in your browser.

You will need to register with community.jenkins.io either using an existing account (like a GitHub account) or by creating a new account dedicated to community.jenkins.io and then "Join" the "election-voter" group.

2021 10 25 jenkins elections

Am I Eligible to Vote?

You’re eligible to vote if you have made at least one contribution to Jenkins before September 1, 2021. Contributions to Jenkins are recognized in many different forms, including:

  • Connect with other users through mailing lists or chat channels

  • Meet with other users in conferences or online meetups

  • Code improvements for Jenkins core, Jenkins plugins, or Jenkins infrastructure

  • Help other users through chat channels or mailing lists

  • Translate Jenkins software or other materials

  • Test Jenkins software interactively or with automation

  • Document Jenkins core, Jenkins plugins, or Jenkins infrastructure

  • Design Jenkins user interface, Jenkins artwork, or other Jenkins

  • Review changes to code or documentation that are submitted by others

  • Donate funds to help the project

If you’ve helped someone use Jenkins or a Jenkins derived product, you’re eligible to vote. If you’ve tested Jenkins interactively or with automation, you’re eligible to vote. If you’ve assisted at a Jenkins meetup or other Jenkins event, you’re eligible to vote.

Nominations

Nominations for candidates are being accepted by the Jenkins election committee. Nominations will close at the end of the day, October 31, 2021. Nominees will be notified and will be asked to confirm that they are willing to serve if elected. The list of candidates for each position will be announced November 7, 2021.

Who Nominates a Candidate?

Anyone may propose a nomination. Nominations are being accepted for the following positions:

Use Just Enough Pipeline

$
0
0

2021 10 26 just enough pipeline

Jenkins Pipeline (or simply Pipeline with a capital P) is a suite of plugins that supports implementing and integrating continuous delivery pipelines into Jenkins. This allows you to automate the process of getting software from version control through to your users and customers.

Pipeline code works beautifully for its intended role of automating build, test, deploy, and administration tasks. But, as it is pressed into more complex roles and unexpected uses, some users have run into snags. Using best practices – and avoiding common mistakes – can help you design a pipeline that is more robust, scalable, and high-performing.

We see a lot of users making basic mistakes that can sabotage their pipeline. (Yes, you can sabotage yourself when you’re creating a pipeline.) In fact, it’s easy to spot someone who is going down this dangerous path – and it’s usually because they don’t understand some key technical concepts about Pipeline. This invariably leads to scalability mistakes that you’ll pay dearly for down the line.

Don’t make this mistake!

Perhaps the biggest misstep people make is deciding that they need to write their entire pipeline in a programming language. After all, Pipeline is a domain specific language (DSL). However, that does not mean that it is a general-purpose programming language.

If you treat the DSL as a general-purpose programming language, you are making a serious architectural blunder by doing the wrong work in the wrong place. Remember that the core of Pipeline code runs on the controller. So, you should be mindful that everything you express in the Pipeline domain specific language (DSL) will compete with every other Jenkins job running on the controller.

For example, it’s easy to include a lot of conditionals, flow control logic, and requests using scripted syntax in the pipeline job. Experience tells us this is not a good idea and can result in serious damage to pipeline performance. We’ve actually seen organizations with poorly written Pipeline jobs bring a controller to its knees, while only running a few concurrent builds.

Wait a minute, you might ask, “Isn’t handling code what the controller is there for?” Yes, the controller certainly is there to execute pipelines. But, it’s much better to assign individual steps of the pipeline to command line calls that execute on an agent. So, instead of running a lot of conditionals inside the pipeline DSL, it’s better to put those conditionals inside a shell script or batch file and call that script from the pipeline.

However, this raises another question: “What if I don’t have any agents connected to my controller?” If this is the case, then you’ve just made another bad mistake in scaling Jenkins pipelines. Why? Because the first rule of building an effective pipeline is to make sure you use agents. If you’re using a Jenkins controller and haven’t defined any agents, then your first step should be to define at least one agent and use that agent instead of executing on the controller.

For the sake of maintaining scalability in your pipeline, the general rule is to avoid processing any workload on your controller. If you’re running Jenkins jobs on the controller, you are sacrificing controller performance. So, try to avoid using Jenkins controller capacity for things that should be passed off to an agent. Then, as you grow and develop, all of your work should be running agents. This is why we always recommend setting the number of executors on the master to zero.

Use Just Enough Pipeline to Keep Your Pipeline Scalable

All of this serves to highlight our overarching theme of “using just enough pipeline.” Simply put, you want to use enough code to connect the pipeline steps and integrate tools – but no more than that. Limit the amount of complex logic embedded in the Pipeline itself (similarly to a shell script), and avoid treating it as a general-purpose programming language. This makes the pipeline easier to maintain, protects against bugs, and reduces the load on controllers.

Another best practice for keeping your pipeline lean, fast, and scalable is to use declarative syntax instead of scripted syntax for your Pipeline. Declarative naturally leads you away from the kinds of mistakes we’ve just described. It is a simpler expression of code and an easier way to define your job. It’s computed at the startup of the pipeline instead of executing continually during the pipeline.

Therefore, when creating a pipeline, start with declarative, and keep it simple for as long as possible. Anytime a script block shows up inside of a declarative pipeline, you should extract that block and put it in a shared library step. That keeps the declarative pipeline clean. By combining declarative with a shared library, that will take care of the vast majority of use cases you’ll encounter.

That said, it’s not accurate to say that declarative plus a shared library will solve every problem. There are cases where scripted is the right solution. However, declarative is a great starting point until you discover that you absolutely must use scripted.

Just remember, at the end of the day, you’ll do well to follow the adage: “Use just enough pipeline and no more.”

Thanks to our Sponsor

Mark and Darin both work for CloudBees. CloudBees helps Fortune 1000 enterprises manage and scale Jenkins. Thanks to CloudBees for sponsoring the creation of this blog post.

Mark and Darin joined Hope Lynch and Joost van der Griendt to share additional topics in a CloudBees on-demand recording, "Optimizing Jenkins for the Enterprise". Register for the on-demand recording to receive more information on configuration as code, plugin management, and Pipelines.

Introducing external storage for JUnit test results

$
0
0

In common CI/CD use-cases a lot of the space is consumed by test reports. This data is stored within JENKINS_HOME, and the current storage format requires huge overheads when retrieving statistics and, especially, trends. In order to display trends, each report has to be loaded and then processed in-memory.

The main purpose of externalising Test Results is to optimize Jenkins performance and storage by querying the desired data from external storages.

I’m please to announce that the JUnit Plugin external storage is now available for use.

Getting started

Install your database vendor specific plugin, you can use the Jenkins plugin site to search for it:

e.g. you could install the PostgreSQL Database plugin.

We currently support PostgreSQL or MySQL, but can support others, just create an issue or send a pull request.

From Jenkins UI

Navigate to: Manage Jenkins → Configure System → Junit

In the dropdown select 'SQL Database'

JUnit SQL plugin configuration

Now configure your Database connection details.

Search for 'Global Database' on the same 'Configure System' page.

Select the database implementation you want to use and click 'Test Connection' to verify Jenkins can connect

JUnit SQL plugin database configuration

Click 'Save'

Configuration as code

If you want to configure the plugin via Configuration as Code then see the below sample:

unclassified:globalDatabaseConfiguration:database:postgreSQL:database: "jenkins"hostname: "${DB_HOST_NAME}"password: "${DB_PASSWORD}"username: "${DB_USERNAME}"validationQuery: "SELECT 1"junitTestResultStorage:storage: "database"

Using the plugin

Now run some builds, here’s an example pipeline configuration to get you started if you’re just trying out the plugin:

node {
  writeFile file: 'x.xml', text: '''<testsuite name='sweet' time='200.0'><testcase classname='Klazz' name='test1' time='198.0'><error message='failure'/></testcase><testcase classname='Klazz' name='test2' time='2.0'/><testcase classname='other.Klazz' name='test3'><skipped message='Not actually run.'/></testcase></testsuite>'''
  junit 'x.xml'
}

You will see a test result trend appear like below on the builds project page:

JUnit Trend

If you check on the controller’s file system you will see no junitResult.xml for new builds.

If you connect to your database and run:

SELECT * FROM caseresults;

You will see a number of test results in the database.

What happens to existing test results?

Existing test results will stay on disk but will not be loaded.

Currently there is no migration scripts or plugin functionality to do this, if you need it then please raise an issue.

How are test results cleaned up

When a job or build is deleted the related test results are removed.

This is expected to be done as part of a 'Build Discarder'.

If you wish to keep your results longer than this you can disable this feature by enabling:

Skip cleanup of test result on build deletion on the system configuration page.

If you need more complex cleanup strategies built into the plugin then please raise an issue.

API

The API is defined at:

JunitTestResultStorage#load is passed a job name and build which can be used to construct an instance of the external storage implementation.

This implementation will then act on that job and build except for the optimised calls that act across all builds.

The API contains the basic methods like getFailCount, getSkipCount, but also APIs that are optimised for retrieving data for the trend graphs on the job page and the test result history page.

These allow single API calls to be made for what used to be a lot of work for Jenkins to look up before.

Feedback

I would love to hear your feedback & suggestions for this feature.

Please create an issue at https://github.com/jenkinsci/junit-plugin or provide feedback on https://community.jenkins.io


Jenkins in Hacktoberfest 2021

$
0
0

2021 10 31 hacktoberfest results 2021

Hacktoberfest 2021 made great contributions to the Jenkins project. We thank all the Hacktoberfest contributors and the maintainers who reviewed the submitted pull requests.

We received contributions in artwork, translation, documentation, security, and general purpose improvements. The contributions included software improvements, documentation updates, and video tutorials.

Translations and Artwork

Duchess France provided significant improvements to the French localization of Jenkins. The changes included new translations of text, corrections of existing translations, and file encoding fixes. The translation changes included fifteen pull requests representing the work of six different contributors.

Translation pull requests were also received for Spanish language improvements. The translation pull requests included multiple plugins in addition to Jenkins core.

A contributor from "Duchess France [Women in tech]" created the first Jenkins logo highlighting a woman. Special thanks to tatoberres for the new artwork!

256

Thea Mushambadze created the new Jenkins logo for Georgia logo.

georgia

Thanks very much!

Plugin Docs Migration to GitHub

The Jenkins project started the migration of plugin documentation to GitHub almost two years ago. Hacktoberfest 2021 identified 40 candidate plugins to migrate their documentation to GitHub.Dan Heath,Deepak Gupta,Avinash Upadhyaya K R,Rajan Kumar Singh, andDheeraj Singh Jodha provided a total of 29 pull requests migrating plugin documentation to GitHub.

Special thanks to the contributors and to the plugin maintainers that merged and released documentation migration pull requests. Eight plugins have fully migrated their documentation to GitHub through Hacktoberfest contributions. An additional thirteen plugins have merged the documentation change and will complete the migration with their next plugin release.

The plugin documentation migration was coordinated through a worksheet. A tutorial video describing the documentation migration process is also available.

Implementing Content Security Policy

Wadeck Follonier provided a tutorial to prepare Jenkins for a broader implementation of Content Security Policy. Six contributors provided pull requests to Jenkins core to create separate JavaScript files from JavaScript that was previously implemented inside the Jenkins 'jelly' files. Moving JavaScript into separate files prepares Jenkins to implement Content Security Policy protections against JavaScript embedded in HTML.

Jenkins Architecture Diagrams

Angélique Jard provided architectural diagrams showing a dataflow view of Jenkins and a high level view of Jenkins. Those diagrams help others understand the internal structure of Jenkins and how it interacts with users and with other systems.

jenkins dataflow

Modernizing Plugins Video Series

Darin Pope created five videos illustrating some of the small steps that a new contributor can use to help modernize a plugin. Additional plugin modernization and adoption ideas are included in the "Contributing to Open Source" workshop from DevOps World 2021.

Modernizing Jenkins Plugins

Thanks to All

We offer our most sincere thanks to all Hacktoberfest contributors and to the many pull request reviewers.

Guava library upgrade (breaking changes!)

$
0
0

Guava Upgrade

Summary

Jenkins bundles Guava, a core Java library from Google. Beginning with Jenkins 2.320 (released on November 10, 2021), Jenkins has upgraded the Guava library from11.0.1 (released on January 9, 2012) to31.0.1 (released on September 27, 2021). Plugins have already been prepared to support the new version of Guava in JEP-233.Use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.320.

Motivation

Many security-conscious organizations using, or planning to use, Jenkins run off-the-shelf security scanners to look for known vulnerabilities. These commonly flag the obsolete Guava library as susceptible to a serialization-related vulnerability (CVE-2018-10237) and recommend upgrading. While Jenkins uses JEP-200 to form an explicit list of allowed classes for deserialization, and the two Guava classes affected by CVE-2018-10237 are not and will never be added to the list, it is time-consuming for the security team to respond to purported security reports and for users to justify exemptions from policy to use Jenkins anyway.

Furthermore, the decade-old version of Guava has long been a maintenance burden for Jenkins developers. In a world where Dependabot offers upgrades to libraries released just hours before, it is unpleasant to be working with dependencies that are many years old.

For more information, see JEP-233.

Upgrading

The vast majority of plugins have already been prepared to support the new version of Guava in JEP-233. Jenkins users need only upgrade plugins to compatible versions as documented in the "Released As" field in Jira.It is critical to use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.320. Failure to upgrade plugins to compatible versions may result in ClassNotFoundException, NoClassDefFoundError, or other low-level Java errors.

Reporting issues

If you find a regression in a plugin, please file a bug report in Jira:

When reporting an issue, include the following information:

  1. Use the JEP-233 label.

  2. Provide the complete list of installed plugins as suggested in the bug reporting guidelines.

  3. Provide the complete stack trace, if relevant.

  4. Provide steps to reproduce the issue from scratch on a minimal Jenkins installation; the scenario should fail when the steps are followed on Jenkins 2.320 or later and pass when the steps are followed on Jenkins 2.319 or earlier.

If you maintain a Jenkins plugin with an open JEP-233 issue, then please check if there is a pull request awaiting merge or release. If you use an unmaintained Jenkins plugin with an open JEP-233 issue, consider stepping up and adopting the plugin to release a compatible version.

Conclusion

We expect to see a bit of disruption from these changes but hope that in the long run they will save time for core and plugin developers and lead to a more secure and stable tool. Please reach out on the developers' list with any questions or suggestions.

Interview of Duchess contributors for hacktoberfest 2021 on Jenkins

$
0
0

Jenkins and Duchess

This year, the Duchess community embraced a new challenge: working on women’s presence in Open Source while participating in Jenkins during the Hacktoberfest, a yearly event.

Huge congrats to all the contributors! 🥳

Note: This blog is a translation, the source blog post is located here https://www.duchess-france.org/duchess-hacktoberfest-2021/

Anne-Laure Gaillard Interview

Hello Anne-Laure, can you introduce yourself?

Anne-Laure Gaillard picture

After a PhD in Computer Science and a few years in Software Development, I specialized in software quality assurance, and particularly in the testing domain. I’m a supporter of the doctrine: “Quality is everyone’s business”. Fond of agility, I’m part of the organization committee of the Agile Tour Bordeaux since 2020.

I also like to engage in sporting challenges: I swam across the Garonne (a big river in the south of France) and finished 2 triathlons. Keeping the best for the end: I’m the mother of two kids who taught me it’s possible to speak about Pokemon with one, while drawing a unicorn with the other.

What did you think about Open Source, and maybe Jenkins, before starting the hackathon?

During my studies, I met quite a lot of “nerds / geeks” contributing to Linux distributions (Gentoo & Debian). Their technical skills seemed higher than mine and the Open Source universe looked inaccessible to me. Concerning Jenkins, I am a user (now contributor) of it, but not an administrator.

What motivated you to participate in that hackathon?

I dared to participate thanks to the Duchess (and mainly Angélique, thanks to her). Having the support and backing of the community was my motivation.

What will you remember from this experience?

From a professional point of view, I perfected my knowledge of Git, and I had a chance to overview part of the quality processes from Open Source projects. My first Pull Request was approved by… 9 people! The fourth reviewer did find an issue. Who can tell me code review isn’t useful now?

From a personal perspective, I remember two things. The first one: Open Source communities are not elitist communities. Every contribution matters, even small ones. The people I met were positive and benevolent. The second one could be illustrated by a quote from Grace Hopper: “If it’s a good idea, go ahead and do it. It’s much easier to apologize than it is to get permission.”.

Do you have anything more to say?

After Jenkins, I also submitted Pull Requests to others Open Source projects. The problem: with such a diversity of Open Source projects, how to organize your time?

Bertha Torres Interview

Bertha Torres picture

Hello Bertha, can you introduce yourself?

Coming from a literature training and as a language teacher for more than 15 years, it’s while moving to a high mountain area that a need to explore other skills set in.

Thus, a self-taught training followed by a validated file for financing diploma training followed one another and confirmed to me that life is too short to waste it on what does not make sense to us.

What did you think about Open Source, and maybe Jenkins, before starting the hackathon?

Participating in Open Source appeared to me in that exploratory process like a learning opportunity… which I thought was inaccessible of course! I didn’t see myself writing code.

But thanks to the Duchess France community, I learned how to contribute at my level and to understand the contribution process. It’ll allow me as things progress to contribute in more domains.

Can you tell us how the woman version of Jenkins was born?

Well… In the presentation video for Hacktoberfest, the artwork was mentioned (https://www.jenkins.io/artwork/) and Angélique also mentioned it during the first meeting… And one must admit that looking at it, you can see a lot of different things but women.

So I imagined a governess, very confident, efficient, very clever, scrupulously combed, nicely dressed, who might represent the personality of what Jenkins is made of.

Do you have anything to add?

This time I was able to participate through Pull Requests related to translation and drawing. I’ll probably do it again!

Pauline Iogna’s Interview

Pauline Iogna picture

Hello Pauline, can you introduce yourself?

I’m a backend developer in Java/Scala, and an active member of Duchess France.

What did you think about Open Source, and maybe Jenkins, before starting the hackathon?

I didn’t really have an opinion about Jenkins before doing the hackathon. Like many other people, I’m a Jenkins user but I didn’t know its source code.

What motivated you to participate in this hackathon?

Actually participating in Hacktoberfest. Just bringing a contribution, even modest, on an open source project.

What did you discover through that hackathon?

Technically, I discovered how to do MVC with Apache Jelly. I also rediscovered the contribution process of Open Source projects.

The Hacktoberfest mechanism is really well thought out for onboarding people wanting to start working on Open Source projects. With Angélique’s help on top of that to animate sessions on the Duchess France Slack channel, we had the best conditions to contribute to that important project.

What will you remember from this experience?

It’s not that simple to contribute to a project you’re just discovering, it requires a bit of investment and patience. On Jenkins, the contributors are really reactive and the Pull Requests are quickly reviewed. The feedback is useful and benevolent. There is one Jira project listing all the features and bugs to be worked on for the project. Some tickets are flagged as “newbie” allowing those who are beginners to pick easily and quickly doable tickets.

A few words about the organization within Duchess France

The framework was intentionally simple and flexible. We started with an online kick start meeting for describing a bit of context, and more precisely the Jenkins universe.

Online kick start meeting for context

Then, we mainly exchanged through the Duchess Slack channel in an asynchronous way on a dedicated channel, as well as a 30 minutes meeting each Friday during October.

2021 Jenkins Board and Officer Elections Results

$
0
0

Jenkins Elections

The Jenkins community has recently completed the 2021 elections. On behalf of the Jenkins community and the elections committee, we congratulate all newly elected board members and officers! We also thank all candidates and voters who participated this year.

Election results:

The board positions and officer roles are an essential part of Jenkins' community governance and well-being, and we are excited to see contributors taking these roles.

The board continues to require that no single company may have a majority on the Jenkins governance board. Oleg Nenashev is employed by Dynatrace, while Mark is employed by CloudBees.

Governance Board election details

This year we had three candidates participating in Jenkins Governance Board elections: Mark Waite, Oleg Nenashev (returning), and Ullrich Hafner (returning) All of them are awesome community leaders who actively contribute to the Jenkins project and represent its users. It would be an honor to have them on the Jenkins board. Regardless of the election results, we appreciate their participation and the time they invested in these elections.

This year we were electing 2 governance board members. We were using the Condorcet Internet Voting Service that allows voters to rank their choices rather than just picking their one favorite choice. You can find full voting results here:

  1. Mark Waite (Condorcet winner: wins contests with all other choices)

  2. Oleg Nenashev loses to Mark Waite by 37–22

  3. Ullrich Hafner loses to Mark Waite by 42–14, loses to Oleg Nenashev by 37–15

Congratulations to the returning Oleg, and the newly elected Mark, and thanks to Ullrich for his past contributions. All new board members are elected for a 2-year term unless they decide to step down earlier. The estimated end of the term for them is December 02, 2022.

Officer election details

All 5 officer positions were up for election this year. These roles have a 1-year term, with the estimated end of term on Dec 02, 2022. After the initial review of nominations and confirmations with potential candidates, 4 officer positions were uncontested:

Thanks to all Jenkins officers for their continued leadership! Officers take responsibility for many day-to-day processes in the Jenkins community and lead the contributor teams working on them. It requires significant time commitment, and it is not taken for granted.

Statistics

This year we had 81 registered voters and around 59 actual votes.

Feedback

The Jenkins project plans to conduct elections every year. We appreciate and welcome feedback regarding the election process so that we can improve the process. We have started a Retrospective document for these elections. Everyone can suggest changes in this document, and we will integrate them.

If you have any private feedback you would like to share, please send an email to the Jenkins Board. If you would like to raise any issues about the election process, please contact one of the elected Governance Board members.

Use Containers as Build Agents

$
0
0

A continuous integration environment is a mixed bag of machines, platforms, build toolchains and operating systems. Ideally, you want as much flexibility as possible in managing these environments. You want your build machines to be interchangeable and you don’t want to tie your builds to a particular machine. Using containers as build agents is an effective way to get the flexibility you need to create applications faster and more effectively.

Most modern software organizations recognize the benefits of deploying and managing applications as containers. And now more organizations are using containers to unify their build and test environments across machines, and to provide an efficient mechanism for deploying applications.

If you’re new to containers, think of it as the next step beyond virtualization. It consists of a set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers. A container image contains everything it needs to run independently of the server on which it lives: It contains a copy of the operating system, along with your application. That could include a database, code, configuration files, dependencies, and so forth.

Containerization is a great way to simplify migration of Jenkins instances to different machines, as well as simplify ongoing maintenance and upgrades. Starting with versions 2.5 and higher, Jenkins Pipeline has built-in support for interacting with Docker from within a Jenkinsfile.

Although you can install and upgrade Jenkins using OS-installable packages, the container images of Jenkins take installation and upgrades to a new level, removing a lot of the complications with maintaining the Jenkins installation. That’s one of the main reasons you should prefer the container images of Jenkins over OS-specific installation packages.

Using containers as build agents for greater Pipeline flexibility

What about using containers in your build agents? You’ll recall that Jenkins agents are the "workers" that perform operations requested by the Jenkins controller.

What is a Jenkins agent?

Many of you have been writing Jenkins pipelines for awhile, but you’ve been constrained by the tooling that’s available on your agent. But what if you no longer had to be constrained by specific versions of specific tools on specific agents? And that you had full control over the tooling that you’re using just by having Docker available on your agents?

Well, that is exactly what’s possible by using containers as build agents for Jenkins. To learn how to set up your agents with Docker, watch this step-by-step video.

How to Setup Docker Containers As Build Agents for Jenkins

So why would you want to use a container as your build agent? As a pipeline author, it gives you the ability to define the tools and the specific versions of those tools that you want to use in your pipeline so that those items are not being mandated or managed by others.

Secondly, if in your environment, someone else has to install the tools for you on your agent, you can completely bypass all of that because you’re able to dynamically bring in the tools that you want or need at runtime.

Finally, it gives you the chance to experiment with different tools without having to make a long-term commitment to those tools. Because if you have a dependency on someone else installing tools for you, that might take a long time. But by running it as a container, you can test it out, and if it works, great! Then you have the option to work with somebody else to get static versions of those tools installed on your agents, or you can just stay with your container-based build agents.

Thanks to our Sponsor

Darin works for CloudBees. CloudBees helps Fortune 1000 enterprises manage and scale Jenkins. Thanks to CloudBees for sponsoring the creation of this blog post.

Apache Log4j 2 vulnerability CVE-2021-44228

$
0
0

A critical security vulnerability has been identified in the popular "Apache Log4j 2" library. This vulnerability is identified as CVE-2021-44228.

Log4j in Jenkins

The Jenkins security team has confirmed that Log4j is not used in Jenkins core. Jenkins plugins may be using Log4j. You can identify whether Log4j is included with any plugin by running the following Groovy script in the Script Console:

org.apache.logging.log4j.core.lookup.JndiLookup.class.protectionDomain.codeSource

If this results in the following error, Log4j is not included in any installed and enabled plugin:

groovy.lang.MissingPropertyException: No such property: org for class: Script1

Otherwise, the script output will print one location where Log4j is found, which includes the plugin name in the path. That plugin should be disabled or uninstalled, followed by a Jenkins restart and another script execution until the "No such property" error appears.

Affected plugins and their mitigation status are listed in the Jenkins issue tracker. See this Jira query for components known to be affected.

Log4j in web application containers

If you are hosting your Jenkins in a separate web application container like Tomcat, Websphere, or Glassfish, check with the providers of those containers to assess if they are using a vulnerable version of Log4j.

When Jenkins runs from the Docker image, a native installer package (deb, rpm, msi), or is invoked with java -jar jenkins.war, it is not running inside a separate web application container. It is using the built-in Jetty web application container that is bundled inside Jenkins and does not include Log4j.

Log4j in Jenkins project infrastructure

The Jenkins infrastructure team is currently checking all Jenkins project infrastructure for the presence of vulnerable versions of the Log4j library. This work is ongoing. We may decide to disable some services temporarily out of an abundance of caution. You can see the status of services on the status page.

Deprecating non-Java plugins

$
0
0

Deprecating non-Java plugins

10 years ago, the Jenkins ruby-runtime was first released. It was an experiment to let plugins be written in ruby but still get integrated into the main Java Virtual Machine runtime with help of JRuby. A similar extension was made to allow plugins to be written in Python but still integrated into the Java Virtual Machine with Jython.

Over the years though, the experiments are no longer being maintained and the plugins that use the non-Java runtimes take a lot of compatibility effort. In addition, the Jenkins ruby runtime does not support Java 11. Specifically, the last few years have been really hard on the Jenkins core developers, as they still have to maintain all the hacks and processes to keep the non-Java runtimes barely working. Examples of the experienced issues include compatibility with JEP-200: Switch Remoting/XStream blocklist to a permitlist where we had to allow many Ruby Runtime classes in the Jenkins core to support serialization of data.

In 2018 we discussed the future of the Ruby Runtime based plugins. There was a consensus that we want to deprecate and remove the plugins so that Jenkins users do not experience issues .Daniel Beck created JEP-7: Deprecation of ruby-runtime for that. Over the years, the functionality provided by Ruby plugins has been largely replaced by other implementations, and hence we have decided to proceed with the deprecation (discussion).

One month from now, January 22nd, 2022, the default Jenkins update center will stop distributing the Ruby runtime plugin, the plugins that use the Ruby runtime, the Python runtime plugin, and the plugin that uses the Python runtime.

What does this mean for you?

If you are one of the few users who are using the following plugins, there will be no impact on your existing instances. The only change will come for new installs. Suspended plugins will stay installed, but can not be newly installed without manually downloading releases or using custom update centers.

Jenkins plugin management tools and distributions may be affected as well if they use the default update center to download the plugins and/or their metadata. It includes but is not limited to the official Docker images,Helm charts,Jenkinsfile Runner,Custom Jenkins WAR Packager, and the Plugin Installation Manager CLI Tool. Note that all these tools allow custom update sites to be configured if required.

The lists below provide additional information about the plugins based on the Ruby Runtime and the Python Runtime. Please plan your transition away from these plugins. They will be removed from the official Jenkins update centers on January 22, 2022.

Affected plugins

Gitlab Hook

Last released 6 years ago.
Contains multiple security vulnerabilties.
Suggestion: Use the GitLab plugin and the GitLab Branch Source plugin.

Cucumber

Last released 9 years ago.
Suggestion: Use sh or bat to run cucumber from the command line.

pyenv

Last released 7 years ago.
Suggestion: Use sh or bat to run pyenv from the command line.

Rvm

Last released 5 years ago.
Suggestion: Use sh or bat to run rvm from the command line.

Capitomcat

Last released 7 years ago.
Suggestion: Install Ruby and Capistrano and use sh or bat to invoke them from the command line.

Commit Message Trigger

Last released 7 years ago.
Suggestion: Use sh, bat, or other scripts to read git commit messages and conditionally execute Pipeline steps.

Git notes

Last released 10 years ago.
Suggestion: Use sh, bat, or other scripts to run git to annotate commits.

rbenv

Last released 6 years ago.
Suggestion: Use sh or bat to run rbenv from the command line.

Chef

Last released 6 years ago.
Suggestion: Use sh or bat to run chef from the command line.

CI Skip

Last released 8 years ago.
Suggestion: Use the GitHub Commit Skip SCM Behaviour, Bitbucket Commit Skip SCM Behaviour, or SCM Skip to skip builds based on the content of commit messages. Alternately, use sh, bat, or other scripts to read git commit messages and conditionally execute Pipeline steps.

InstallShield

Last released 8 years ago.
Suggestion: Use sh, bat, or other scripts to run InstallShield.

MySQL Job Databases

Last released 7 years ago.
Suggestion: Use Jenkins Job Database Manager Plugin for MySQL.

Pathignore

Last released 10 years ago.
Suggestion: Use the path ignore features of various plugins or use sh, bat, or other scripts to read git commit messages and conditionally execute Pipeline steps.

Perl

Last released 9 years ago.
Suggestion: Use sh or bat to run perl from the command line.

pry

Last released 10 years ago.
Suggestion: Use the Jenkins groovy console and its interface from the Jenkins command line interface.

Single Use Agent

Last released 7 years ago.
Suggestion: Use cloud agents (Fargate, Azure Container Instances, Docker, etc.) to allocate agents for a single use and then release them.

Travis YML

Last released 5 years ago.
Suggestion: Rewrite the travis.yml file as a Jenkinsfile, a Jenkins Templating Engine file, a Pipeline as YAML, or a Jenkins Modular Pipeline Library.

Yammer

Last released 8 years ago.
Suggestion: Use the Yammer REST API to post messages.

DevStack

Last released 9 years ago.

Ikachan

Last released 10 years ago.

Jenkinspider

Last released 7 years ago.

Perl Smoke Test

Last released 7 years ago.

buddycloud

Last released 8 years ago.

Acknowledgements

We would like to thank all contributors and maintainers who contributed to the Ruby Runtime based plugins and the Python Runtime based plugin. We also thank those who participated in development of new plugins replacing the functionality. These contributors helped millions of Jenkins users while the ecosystem was supported over the past 10 years and it is not taken for granted. Now we need to move on so that we can keep expanding the Jenkins architecture and developers tools. We invite all contributors to participate in this effort and to help us to migrate the plugins to supported JVM-based platforms for plugins.

My instance is affected, what to do next?

If you do not use the affected plugins, the recommendation is to remove them. Otherwise, it is recommended to start migration out of the plugins to alternatives providing similar functionality.

Not all plugins have alternatives. At the moment the Jenkins core team does not plan to provide a replacement, but any contributions are welcome. If you depend on the functionality, we recommend reaching out to the community in the developer mailing list so that you can coordinate the replacement with other affected users.


Google Summer of Code 2022 call for Project Ideas and Mentors

$
0
0

Google Summer of Code (GSoC) is a global, online mentoring program focused on introducing new contributors to open source software development. GSoC contributors work on a 12+ week programming project with the guidance of mentors from their open source organization. During GSoC, participating contributors are paired with mentors from open source organizations, gaining exposure to real-world software development techniques. GSoC contributors will learn from experienced open source developers while writing code for real-world projects! A small stipend is provided as an incentive.

See GSoC contributor eligibility here.

We are looking for project ideas and mentors to participate in GSoC 2022. GSoC project ideas are coding projects that potential GSoC contributors can accomplish in about 12+ weeks. The coding projects can be new features, plugins, test frameworks, infrastructure, etc. Anyone can submit a project idea, but of course we like it even better if you mentor your project idea.

Please send us your project ideas before the beginning of February so they can get a proper review by the GSoC committee and by the community.

How to submit a project idea

Create a pull-request with your idea in a .adoc file in the project ideas. It is not necessary to submit a Google Doc, but it will still work if you want to do that. See the instructions on submitting ideas which include an .adoc template and some examples.

Current list of ideas

Below is a current list of proposed project ideas for GSoC contributors to review. Note that this list is still evolving and is subject to change. A final list along with project details and descriptions is coming soon.

  • Jenkinsfile Runner Action for GitHub Actions (Mentors: Oleg Nenashev, Kris Stern)

  • Automatic Specification Generator for Jenkins REST API (Mentors: Kristin Whetstone)*

  • Plugin Health Scoring System - How Should it Work (Mentors: Mark Waite, Adrien Lecharpentier)

  • Configuration as Code Drift Detector (Mentors: Jean-Marc Meessen)*

  • Plugin Installation Manager Tool Improvements (Need new mentors)*

  • Doc Generator (Mentor: Mark Waite)*

  • Automatic Git Cache Maintenance on the Controller (Mentor: Mark Waite)*

  • Improving Cloud Events plugin and aligning it with the emerging CD Events Standard (Mentor: Oleg Nenashev)*

  • Jenkins and OpenTelemetry (Mentor: Oleg Nenashev)*

  • Jenkinsfile executor service for Keptn (powered by Jenkinsfile Runner) (Mentor: Oleg Nenashev)*

(*) additional mentor(s) needed

What does mentoring involve?

Potential mentors are invited to read the information for mentors. Note that being a GSoC mentor does not require expert knowledge of Jenkins. Mentors do not work alone. We make sure that every project has at least two mentors. GSoC org admins will help to find technical advisers, so you can study together with your GSoC contributor. Mentoring takes about 5 to 8 hours of work per week (more at the start, less at the end). Mentors provide guidance, coaching, and sometimes a bit of cheerleading. They review GSoC contributor proposals, pull-requests and contributor presentations at the evaluation phase. They fill in the Google provided final evaluations at the end of the coding period.

What do you get in exchange?

Mentor interaction is a vital part of GSoC. In return for mentoring, a GSoC contributor works on your project full time for 12+ weeks. Think about the projects that you’ve always wanted to do but never had the time… Mentoring is also an opportunity to improve your management and people skills, while giving back to the community. GSoC is a fantastic program and the Jenkins project is happy to participate in GSoC again in 2022!

For any question, you can find the GSoC Org Admins, mentors and participants on the GSoC SIG Gitter chat.

Happy New Year! 2022 edition

$
0
0

Special thanks from the Jenkins project to users and contributors with the New Year! Let’s take a look at some changes this year.

New Year

Highlights

Project updates

The highlights in this blog post do not cover all the advancements in the project.

Additional improvements are noted in the February 2021 Contributor Summit, the June 2021 Contributor Summit, and the October 2021 Contributor Summit. New and updated Jenkins features are described in the LTS changelog and the weekly changelog. The introduction to Jenkins 2.277.1 webinar shares more information on configuration form modernization, the update from acegi to Spring Security, and other dependency updates. See the security advisories archive for more details on security fixes and improvements.

Major events

The Jenkins project participates in major open source events around the world. These events bring new and existing contributors together to improve Jenkins.

Google Summer of Code 2021

Google Summer of Code students

The Jenkins project continued its deep commitment to Google Summer of Code in 2021.

Five Jenkins projects were accepted into Google Summer of Code. All five projects were completed successfully.

Special thanks to the Google Summer of Code students:

Read more about their results and their impact on the Jenkins project in the end of project report.

Hacktoberfest

Hacktoberfest 2021

Hacktoberfest 2021 contributors provided over 90 pull requests to Jenkins repositories. The pull requests included improvements to Jenkins core, Jenkins plugins, Jenkins infrastructure, and Jenkins documentation.

Key results included:

She Code Africa Contributhon

She Code Africa Contributhon 2021

The Jenkins project was a mentoring organization in the first ever She Code Africa Contributhon. The She Code Africa Contributhon pays African women to work with open source organizations on selected projects with dedicated mentors. This program aims to create a more diverse, inclusive, and innovative culture within the African open source ecosystem by matching African women in technology with sponsor and mentor open source organizations.

The five women met with mentors twice weekly for a month. They built Jenkins core and Jenkins plugins and submitted pull requests to improve Jenkins plugin online help and documentation. The 5 mentees on the Jenkins project joined the project from Nigeria, Kenya, and Rwanda.

More details are available in the She Code Africa blogpost.

Sponsors

The Jenkins project is truly fortunate to have so many sponsors contributing to its success. We thank our sponsors sincerely and look forward to their continuing support. The Jenkins project depends on sponsor organizations for its infrastructure, tools, and funding.

Many contributors are employed by sponsor companies like CloudBees and Red Hat.

Jenkins distribution, build, test, and deployment infrastructure is provided by sponsors like JFrog, Amazon Web Services, Oregon State University Open Source Lab, Oracle, and DigitalOcean.

Jenkins development is tracked with tools provided by sponsors like GitHub, JFrog, Atlassian, the Linux Foundation, Netlify, and 1Password. Site search for the Jenkins primary web site and the plugins site is provided by Algolia.

Operational funding is provided by the Continuous Delivery Foundation, CloudBees, and Amazon Web Services.

Core features

Jenkins core delivered 53 weekly releases and 14 long term support releases in 2021. Hundreds of plugin releases were delivered in 2021.

The releases included user interface improvements, security improvements, security fixes, dependency replacements, dependency updates, and more. Contributors from around the world provided the changes included in those releases.

Configuration form modernization

As the culmination of 12 months of work by many different people, Jenkins modernized its configuration forms in Jenkins 2.277.1. The Jenkins user interface is now much better adapted to narrow screens and modern web layout techniques. It works well on all modern web browsers.

The configuration form modernization introduction included a changelog, an upgrade guide, and an introductory webinar.

Dependency updates

Many outdated Jenkins dependencies were updated or replaced by 2021 development work.

The Jenkins core security library was converted from a forked copy of Acegi Security to the most recent release of the standard Spring Security library. The Jenkins core XML serialization library was converted from a forked copy of the XStream library to the most recent release of the standard XStream library. The Jenkins internal class management libraries were converted from a forked copy of Apache Ant libraries to the most recent release of the standard Apache Ant libraries.

Outdated libraries were removed from Jenkins core including ASM 5, ASM 6, Apache Commons Digester, Bytecode Compatibility Transformer, Akuma, Woodstox, JNA Posix, JTidy, and libpam4j. Removals were accompanied by plugin updates as needed to retain compatibility and functionality.

Key libraries were updated to use more recent releases of the libraries. Guava was upgraded from 11.0.1 to 31.0.1. Guice was upgraded from 4.0 to 5.0.1. Groovy was upgraded from 2.4.12 to 2.4.21. Many Apache Commons libraries were upgraded to their most recent releases.

Continuous delivery for plugins

Continuous delivery of Jenkins components was proposed in 2020 by Jesse Glick as Jenkins Enhancement Proposal 229. By the end of 2021, 119 plugins had adopted continuous delivery, providing new plugin releases each time a relevant commit was merged to the plugin repository. Additional components have adopted continuous delivery as well, including the plugin bill of materials and the Jenkins test harness.

We look forward to even greater adoption of continuous delivery for plugins in 2022.

Prefer Java 11 instead of Java 8

Java 11 was adopted as the recommended JDK during 2021. Docker images now use JDK 11 by default. See the blogpost for more information about the Docker image transition.

Docker images with Java 11 are also available for multiple platforms, including 64 bit ARM and IBM s390x.

More inclusive naming

The Jenkins project decided in 2016 to replace the term "slave" with the more inclusive term "agent". In July 2020 the project adopted the "controller" term to replace the older term "master".

Jenkins core 2.319.1 was released in December 2021 replaced the term "master" with more accurate terminology. The release also includes an integrated migration tool to allow existing installations to decide when they would adopt the new terminology.

Security improvements

Jenkins security improvements have continued throughout 2021. The Jenkins security team provided timely responses to security issues in Jenkins core and in Jenkins plugins. The project is sincerely grateful to Daniel Beck for his years of service as Jenkins Security Officer.Wadeck Follonier began his service as Jenkins Security Officer in December, 2021.

The Jenkins infrastructure team resolved infrastructure issues and safeguarded Jenkins infrastructure. The project is deeply grateful to Olivier Vernin for his years of service as Jenkins Infrastructure Officer.Damien Duportal began his service as Jenkins Infrastructure Officer in December, 2021.

Agent to controller security

Daniel Beck proposed Jenkins Enhancement Proposal 235 in November, 2021 to remove the ability to disable or customize the agent-to-controller security system. Telemetry has been added to Jenkins releases beginning with 2.319.1 and Jenkins 2.326. The telemetry reports agent use of methods to access files on the controller. As controller file access from agents is detected by the telemetry, issues are raised to remove that access from the offending plugin.

Log4j 2 zero day vulnerability

December 2021 included the announcement of multiple zero day vulnerabilities in the Apache Log4j 2 library. The Jenkins security team assessed the impact of the vulnerabilities and confirmed that Jenkins core was not affected by the vulnerabilities. Further research showed that Jenkins plugins might be affected by the vulnerabilities. Instructions were shared in a blogpost so that Jenkins administrators could check their system for issues. A Jira epic tracks the progress of corrections in the plugins that were including the affected Apache Log4j 2 library versions.

Jenkins Confluence instance shutdown

In September, 2021, a zero day vulnerability was disclosed in the Confluence version used in the Jenkins project. The infrastructure team permanently disabled the service, rotated privileged credentials, and actively reduced the scope of access across the Jenkins infrastructure. Passwords for all user accounts on jenkins.io were reset. Users were required to perform a password recovery in order to regain access to their jenkins.io accounts. See the blogpost for more details.

The page content from the Jenkins Confluence instance has been returned to service as static HTML pages. The plugin documentation from the Jenkins Confluence instance is now integrated into the plugin site build process.

Master project in Jenkins security

Wadeck Follonier coordinated and mentored an end-of-study security research project for four students during the last year of their Master’s Degree - Reliability and IT Security at the University of Aix-Marseille. The students applied their university training to audit Jenkins core and many Jenkins plugins for specific types of security issues. Their project resulted in 14 vulnerabilities reported in Jenkins security advisories. More details of their results and their processes are available in the blogpost.

Plugin site enhancements

The Jenkins plugins site has become the definitive location for information about Jenkins plugins. It successfully presents plugin documentation, changelogs, and dependencies for over 1100 plugins.

Site search is provided by an Algolia open source sponsorship for easy and accurate search of Jenkins plugins. Search performance reports are used to refine and improve the site.

Jenkins plugin maintainers migrated plugin documentation for over 200 plugins into plugin repositories. Documentation in GitHub repositories is easier to update, easier to manage, and more likely to be correct.

Community site

Community Site

The Jenkins community has improved its communication with the addition of a new internet forum, community.jenkins.io. Discourse sponsors the internet forum management software that runs the community site. The site hosts question and answer forums, highlights novel and interesting use of Jenkins, and encourages users to help one another. See the "2021: Year in Review" page for more details on the use and evolution of the community site.

Jenkins is the way

Jenkins is the Way

"Jenkins Is The Way" is a global showcase of how developers and engineers are building, deploying, and automating great stuff with Jenkins. 138 new user stories were added to the site in 2021. Jenkins use around the world was highlighted in 3 eBooks.

What’s next?

The Jenkins project will be busy in 2022. User experience improvements are arriving. Java updates are continuing. In the coming months there will be discussions on the community site, in the mailing lists, special interest groups, and contributor summits. We invite all teams to work on their roadmaps and to communicate them in the community.

We also plan to continue all outreach programs. At the moment we are looking for Google Summer of Code 2022 mentors and project ideas (announcement). We also work on improving contribution guidelines for newcomers and expert contributors. If you are interested, please contact the Advocacy and Outreach SIG.

And even more

This blog post does not provide a full overview of what changed in the project. The Jenkins project consists of more than 2000 plugins and components which are developed by thousands of contributors. Thanks to them, a lot of changes happen in the project every day. We are cordially grateful to everybody who participates in the project, regardless of contribution size. Everything matters: new features, bug fixes, documentation, blog posts, well reported issues, Stackoverflow responses, etc. THANKS A LOT FOR ALL YOUR CONTRIBUTIONS!

So, keep updating Jenkins and exploring new features. And stay tuned, there is much more to come in 2022!

Why can't I install the latest plugin on my Jenkins LTS?

$
0
0

I regularly go, as all Jenkins admin do, to my system’s Plugin Management page to see what plugins can be upgraded.

Although I am running the latest LTS version, I can’t update some key plugins (for example the JUnit plugin). This is even more intriguing as some are part of the plugins installed by default by the setup wizard. No "install" tick box and the plugin is labeled "unavailable". There is a note saying "This version of the plugin exists but it is not being offered for installation, so the latest bug fixes or features are not available to you. This is typically the case when plugin requirements, e.g. a recent version of Jenkins, are not satisfied. If you are using the latest version of Jenkins offered to you, newer plugin releases may not be available to your release line yet. See the plugin documentation for information about its requirements.".

pluginView

The message indicates to Jenkins administrators that a newer plugin version is available but that the installed Jenkins core doesn’t provide a necessary prerequisite – typically being too old.

Why is this happening now? Did I miss something?

As part of the continuous improvement of Jenkins, some critical and high impact changes are introduced. This is typically the case of GUI changes (icons, fonts, layout) as is currently happening. It is also the case for new core features that can be consumed by plugins.

Such changes are typically first introduced in the cutting edge Jenkins weekly release. Plugins are adapted to take advantage of these changes and the minimal Jenkins version required for those new plugin releases is set to a very new release of Jenkins that includes these changes. This causes a clear requirement disruption compared to the generally slow and low-impact plugin requirement evolution.

It will require more time before these major changes will be available in an LTS Jenkins version. In the meantime, the new plugin will have to wait before it can be installed on that release line.

If you need to install that latest plugin version because it also fixes that annoying bug, you will have to evaluate whether it is worth switching to the weekly release line.

Note that this story is a strong reminder to keep your Jenkins system as current as possible if you don’t want to miss out on new features and important bug fixes.

Special thanks to Daniel Beck to have given me the "raw" explanation of this unexpected behavior.

Jenkins GSoC 2022: The Return of Students as Mentors

$
0
0

Since 2005, the Google Summer of Code program has connected 18,000+ new open source contributors from 112 countries with 17,000+ mentors from 118 countries. Google Summer of Code has produced over 40 million lines of code for 746 open source organizations.

The Jenkins project has been a mentoring organization for five years, successfully mentored 27 GSoC students by ~80 mentors, not to mention countless numbers of proposed and accepted project ideas.

The Need for More Project Ideas and Mentors

This year, the Jenkins project is gearing up to participate in the GSoC 2022. Just like previous years, an integral element of this program consists of project ideas and mentors. However, Jenkins GSoC 2022 project ideas and mentors are still on the dangerously light side. We are in need of more project ideas and mentors. Please see our previous post for more details on project ideas and mentoring.

Meet our Returning Students, Now Mentors

Natasha Stopa, Abhyudaya Sharma, Kris Stern, Rishabh Budhouliya, and Harshit Chopra

This year, we are especially excited to have former GSoC students join the program as mentors. The following GSoC students turned mentors include:

We asked them to take us through how they came to decide to be GSoC mentors.

What sort of role has mentoring played in your life?

Abhyudaya Sharma

Mentoring has helped me improve my communication skills, meet new people, and learn things in more detail. I feel that by explaining something to someone, you are not only helping them learn, but you also improve your own understanding.

Harshit Chopra

Mentoring helped me explain my thought process more effectively.

Kris Stern

Mentoring has helped me in my work, especially when I need to collaborate with my colleagues. In a way the experience hones my soft skills, so that I have become a more effective communicator.

What made you decide to be a GSoC mentor?

Abhyudaya Sharma

GSoC is not just an opportunity for students to learn new technologies and improve their programming skills, it is much more than that. As a GSoC student in 2019, the feedback from the community members made me realize that even a single project can lead to a substantial improvement in the quality of life of its users. Hence, I’m back this year as a mentor to help the amazing Jenkins ecosystem become even better.

Harshit Chopra

I had great experience as a mentee in GSoC 2021. The mentors and community support made it possible. So I decided to give back to the community.

Kris Stern

I have learned a lot from my previous mentors as well as mentoring community through participation in GSoC as a contributor in 2019 and 2020, and I would like to give back by becoming a mentor myself.

What advice would you share with future GSoC participants?

Abhyudaya Sharma

I wish I knew the importance of writing documentation when I started out as a GSoC student. Writing documentation for your code may seem like a chore at first but with time one realizes that a project is only as good as its documentation. I would recommend future GSoC students to make daily notes of their work and compile them so that they are useful for users and future developers.

Harshit Chopra

I wish I knew that there is no one solution to a problem, sometimes a solution might seem good but could have repercussions. So it’s always good to establish regular communication with the mentors and nice to have a plan B.

Kris Stern

I wish I knew as open-source contributors we do not always know everything, even for the more experienced ones who are in more senior roles in the open-source communities.

What advice would you share with potential mentors?

Abhyudaya Sharma

If you’ve always wanted a new feature or have something fixed, this is the perfect opportunity. Students will be working under your guidance for over three months and will have a chance to create something that would benefit not just you but the entire open-source community. Moreover, mentoring is an excellent opportunity to hone one’s skills and meet new people from all around the world.

Harshit Chopra

If you have the time and want to pass on your experience and knowledge you have gained so far that might help contributors, then mentoring is the best thing for it.

Kris Stern

By taking part in mentoring a new cohort of GSoC contributors we are not just giving, but are learning and benefiting in the process as well. It may seem like we do not have all the necessary skills and knowledge to offer mentorship in a particular project at first, but this can be overcome, especially building on the strengths of our skills and knowledge gained from past GSoC projects as contributors ourselves.

Google Summer of Code 2022… Here We Come!

$
0
0

Jenkins GSoC

We are thrilled to announce that Jenkins has been accepted toGoogle Summer of Code 2022! This will be Jenkins' sixth year as a mentoring organization.

For the past 5 years as a mentoring organization, Jenkins boasts mentorship of 27 GSoC students by 80+ mentors, that’s bringing together over 107 strangers for a common idea - Jenkins.

At the heart of it, GSoC is more than just a mentoring program, bridging new contributors to the open source. It is about giving a little of your day to make a lifetime of a difference, not only for the GSoC contributors but also for the many Jenkins users who will benefit from the improvements.

We are excited to welcome new GSoC contributors to the Jenkins family. We think you will enjoy this valuable experience while developing your technical skills. You will gain insights into how the community works. The best part will be learning from people who are passionate about Jenkins but more importantly they passionate about wanting to make a difference for another individual (GSoC contributors) and for the betterment of the project as a whole.

For detailed information on Jenkins GSoC 2021, see completed projects.

What’s next? GSoC is officially announced, and please expect more potential GSoC contributors to contact projects in ourGitter channels and Discourse channels. Many communications will also happen in SIG and sub-project channels. We will be working hard in order to help potential participants to find interesting projects, to explore the area, and to prepare their project proposals before the deadline on April 19th. Then we will process the applications, select projects and assign mentor teams.

All information about the Jenkins GSoC is available on its sub-project page.

How do I apply?

See the Information for students page for full application guidelines.

We encourage interested participants to reach out to the Jenkins community early and to start exploring project ideas. We also encourage participants to join the weekly Jenkins GSoC office hours, these meetings are set up for participants to meet org admins and mentors and to ask questions. Also, join our Gitter channel and ourDiscourse server to receive information about such incoming events in the project.

The application period starts on April 4th, but you should prepare now! Use the time before the application period to discuss and improve your project proposals. We also recommend that you become familiar with Jenkins and start exploring your proposal areas. Project ideas include quick-start guidelines and reference newbie-friendly issues which may help with initial study. If you do not see anything interesting, you can propose your own project idea.

I want to be a mentor. Is it too late?

It’s not! We are looking for more project ideas and for Jenkins contributors/users who are passionate about Jenkins and want to be a mentor. No hardcore experience required, mentors can study the project internals together with GSoC contributors and technical advisors.

You can either propose a new project idea or join an existing one. See the Call for Mentors post and Information for mentors for details. If you want to propose a new project, please do so as soon as possible so that potential GSoC contributors have time to explore them and to prepare their proposals.

This year mentorship does NOT require strong expertise in Jenkins development. The objective is to guide participants and to get involved into the Jenkins community. GSoC org admins will help to find advisers if special expertise is required.

Important dates for GSoC 2022

  • Mar 7 thru Apr 3 - Potential GSoC contributors discuss application ideas with mentoring organizations. Show us your proposal!

  • Apr 4 - GSoC contributor application period begins

  • Apr 19 - deadline for student applications

  • May 20 - accepted GSoC contributor projects announced, teams start community bonding and coding

  • Sep 04 - coding period ends

  • Sep 20 - Results announced

See the GSoC Timeline for more info.

Viewing all 1088 articles
Browse latest View live