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 at DevOps World 2020

$
0
0

The annual DevOps World, formerly known as DevOps World | Jenkins World is next week - Sept 22-24, with workshops on Sept 25. Just like other events this year, DevOps World pivoted to a virtual event but that doesn’t mean there is a shortage of sessions or networking opportunities. There will be over 50 Jenkins/open source sessions and opportunities to virtually connect with over 20,000+ attendees on the event platform. Below are just a few sessions, the full agenda can be found HERE:

Jenkins: Where It Is and Where It is Going

Date: Tuesday, September 22, 7:00 a.m.-7:30 a.m (PDT)

Speaker: Oleg Nenashev

Jenkins keeps evolving to address demands from its users and contributors: configuration as code, better support of cloud-native technologies, etc. Recently, we have introduced a public roadmap for the project, and there are many key initiatives in development and preview phases. This session will cover the current state of Jenkins and what’s next for the project.

Managing DevSecOps Pipelines at Scale with Jenkins Templating Engine

Date: Tuesday, September 22, 11:30 a.m.-12:00 p.m. (PDT)

Are you currently helping build or maintain a Jenkins pipeline for more than one application or team? Are you tired of copying and pasting Jenkinsfiles and tweaking them to fit each team’s specific needs? This session will feature a live demonstration of getting up and running with the Jenkins Templating Engine (JTE). Attendees will learn how to stop creating bespoke pipelines on a per-application basis and, instead, create tool-agnostic pipeline templates that multiple teams can inherit - regardless of tech stack.

eBay’s Journey Building CI at Scale

Date: Tuesday, September 22, 12:30 p.m.-1:00 p.m.(PDT)

Speakers: Ravi Kiran Rao Bukka & Vasumathy Seenuvasan

A scalable CI platform with 6,000+ Jenkins instances serving around 43,000 builds per day on multi-cluster Kubernetes. A system built with metrics, key resource tuning, remediation’s and security in place. Join this session to hear from eBay on their journey of best practices and learnings about open source.

Machine Learning Plugins for Data Science in Jenkins

Date: Wednesday, September 23, 11:00 a.m.-11:15 a.m.(PDT)

Speaker: Loghi Perinpanayagam

Machine Learning has evolved rapidly in the software industry for recent years. Jenkins CI/CD can be a good practice to deliver a high reliable product in the end. We have done an initial startup on this plugin that can be used to build Jupyter Notebooks, Python files and JSON files in Zeppelin format. In addition, the build wrappers could be used to convert Jupyter Notebooks to Python/JSON and/or copy the files to the workspace for more actions. This Machine Learning plugin will endeavor to satisfy the data science community together with the help of other plugins. Success of this plugin will definitely serve much benefits to the community and Jenkins.

Jenkins UI Gets a Makeover

Date: Thursday, September 24, 7:30 a.m.-8:00 a.m.(PDT)

Speakers: Felix Queiruga& Jeremy Hartley

An overview of the Jenkins UI overhaul. We are taking an iterative approach to gradually refresh the Jenkins UI. This approach will make Jenkins look fresh and modern, without changing the way users are accustomed to working with Jenkins or require plugins to be rewritten to render properly in the new Jenkins UI. Join this session to learn the changes we’ve made and how you can help to improve the Jenkins UI.

The event is free to everyone and recordings will be available on-demand. Registration is required to access the on-demand recordings. And don’t forget to visit the CDF booth in the expo hall for one on one Q&A’s with Jenkins experts.

2020 Jenkins Board and Officer elections. Nominations and voter registration are open!

$
0
0
Jenkins 2020 Elections are over, thanks to all participants! Please see the results announcement.

We are happy to announce the 2020 elections in the Jenkins project! Nominations are open for two governance board and for all five officer positions, namely: Security, Events, Release, Infrastructure, and Documentation. The board positions and officer roles are an essential part of Jenkins' community governance and well-being. We invite Jenkins contributors and community members to sign-up for elections and to nominate contributors for the elected roles. Deadline for nominations is Oct 15, voter registration ends on Nov 02.

These are the second elections held by the Jenkins project. During the 2019 elections, we elected 3 board members and 5 officers. You can find the voting results here. This year, we decided to make a few changes in the election process based on the 2019 elections feedback.

register button

Key dates

  • Sep 24 - Nominations open, voting sign-up begins.

  • Oct 15 - Board and officer nominations deadline.

  • Oct 26 (or later) - List of candidates is published, including personal statements.

  • Nov 10 - Voting begins. Condorcet Internet Voting Service will be used for voting.

  • Nov 24 - Voting sign-up is over.

  • Nov 27 - Voting ends, 11PM UTC.

  • Dec 03 - Election results are announced and take effect.

Signing up for voting

Any Jenkins individual contributor is eligible to vote in the election if there was a contribution made before September 01, 2020.Contribution does not mean a code contribution, all contributions count: documentation patches, code reviews, substantial issue reports, issues and mailing list responses, social media posts, testing, etc. Such a contribution should be public.

You can register to vote in one of two ways:

  1. Fill out this Google Form. This way requires logging into your Google Account to verify authenticity.

  2. Send an email to jenkins-2020-elections@googlegroups.com. You will need to provide the information specified here.

During the registration period, the election committee will process the form submissions and prepare a list of the registered voters. In the case of rejection, one of the election committee members will send a rejection email. Every individual contributor is expected to vote only once.

Deadline for the voter registration is November 24.

Nominating contributors

Suggestions from the community members are highly valued, and the board welcomes additional nominations. If you feel that a particular person is well suited to help guide Jenkins, please submit a name and the reason for your nomination to jenkinsci-board@googlegroups.com. Self nominations are also welcome.

Deadline for nominations is October 15.

Terms

The terms of office for these elected positions are:

  • Officer positions (1 year): December 03, 2020 to December 2, 2021

  • Governing board member (2 years): December 03, 2020 to December 2, 2022

Elections committee

The 2020 elections are coordinated by the Jenkins Governance Board members who are not up for re-election this year:Alex Earl,Ullrich Hafner, andOleg Nenashev. These contributors are responsible for managing the process, preparing the nominee list for elections, forming and verifying the voter list, processing the votes, and announcing the results.

You can contact the election committee via jenkins-2020-elections@googlegroups.com. Please use this email for any queries and feedback regarding the elections.

Documenting Jenkins on Kubernetes Introduction

$
0
0

I’m thrilled to announce that I will be participating in Google Season of Docs (GSoD) 2020 with the Jenkins project. I started contributing to Jenkins documentation during the technical writer exploration phase for Google Season of Docs 2020 and I must say, my journey so far has been nothing short of amazing majorly because of the supportive community behind this project. I chose the Jenkins project because I understood this project from a user point of view as I had been exposed to setting up, configuring, and using Jenkins to automate CI/CD processes. I piqued interest in two of Jenkins project ideas,Plugin documentation migration and update and Document Jenkins on Kubernetes, submitted proposals for these two projects and to my utmost joy, the latter was selected.

In this article, I’m going to be explaining what my selected project is about and why this project is important to the Jenkins community and its users.

Introduction

Kubernetes is a platform-agnostic container orchestration tool created by Google and heavily supported by the open-source community as a project of the Cloud Native Computing Foundation. It allows you to use container instances and manage them for scaling and fault tolerance. It also handles a wide range of management activities that would otherwise require separate solutions or custom code, including request routing, container discovery, health checks, and rolling updates.

Kubernetes is compatible with the majority of CI/CD tools which allow developers to run tests, deploy builds in Kubernetes and update applications with no downtime. One of the most popular CI/CD tools now is Jenkins for the following reasons:

  1. It is open-source and free.

  2. it is user-friendly, easy to install and does not require additional installations or components.

  3. Jenkins is also quite easy to configure, modify and extend.

  4. It deploys code and generates test reports.

  5. It also boasts a rich plugin ecosystem. The extensive pool of plugins makes Jenkins flexible and allows building, deploying and automating across various platforms.

  6. Jenkins can be configured according to the requirements for continuous integrations and continuous delivery.

  7. Jenkins is available for all platforms and different operating systems, whether it is OS X, Windows or Linux.

  8. Most of the integration work is automated. Hence fewer integration issues. This saves both time and money over the lifespan of a project.

The following reasons have made Jenkins on Kubernetes a popular theme for Jenkins users, however, there’s currently no central location for documentation describing Jenkins on Kubernetes, thereby making it difficult for Jenkins on Kubernetes users to navigate and find information. This project would create a new Kubernetes Volume on Jenkins.io which would describe the concepts, techniques, and choices for Kubernetes users running Jenkins.

Current State

There are a lot of presentations and articles about running Jenkins on Kubernetes, however, there’s no central location for describing Jenkins on Kubernetes. This makes it difficult for:

  • Jenkins on Kubernetes users to navigate and find information

  • Track, update and maintain information on Jenkins on Kubernetes

Project Improvements

To solve the existing issue with Jenkins on Kubernetes documentation, a new Kubernetes volume will be created on Jenkins.io. This Volume is going to aggregate user guides, information on cloud providers and demos on Jenkins on Kubernetes. You can find the proposed contents for the new volume here. Feel free to comment on any suggestions you might have in the proposed content doc.

This project will also provide the following advantages:

  • Improve the user experience of Jenkins on Kubernetes users by giving them a one-stop-shop for information on Jenkins on Kubernetes.

  • Make it easy to track, update and maintain information on Jenkins on Kubernetes using the Solutions page

  • Reference the existing community documentation for Jenkins on K8s (plugins and tools/integrations).

  • How to guides, tutorials and explanations of concepts and techniques in Jenkins on Kubernetes.

  • Just-In-Time documentation which means that rather than documenting every feature comprehensively, we will produce and release documentation in bits but continuously based on popular questions, feedback and area of interests gathered from the community and users.

Project Timeline

Find below a summary of the project timeline.

Community bonding (August 17 - September 13)

  • Set up a communication channel and time (due to time difference).

  • Refine my goals and set expectations on both sides.

  • Learn more about the community and Jenkins.

  • Gather and thoroughly study existing resources that will be useful and helpful to the project.

  • Pre-planning of the project

  • Contacting Stakeholders and onboarding contributors

Documentation Period

This period is going to be focused on creating contents which include user guides, tutorials, demos, etc. for Jenkins on Kubernetes. Some of the topics to be covered include Installing Jenkins on Kubernetes, Administering Jenkins on Kubernetes, Cloud providers and much more.

Documentation Timeline

1st Month (September - October)

Some basic prerequisites for installing jenkins on kubernetes include docker, a kubernetes cluster, and optionally Helm or the Jenkins Operator for Kubernetes.

Helm is a package manager which automates the process of installing, configuring, upgrading, and removing complex Kubernetes application. A Helm chart defines several Kubernetes resources as a set. Helm can make deployments easier and repeatable because all resources for an application are deployed by running one command.

Helm has two elements, a client (helm) and a server (Tiller). The server element runs inside a Kubernetes cluster and manages the installation of charts. With Helm, configuration settings are kept in values.yaml file separate from the manifest formats. The configuration values can be changed according to application need without touching the rest of the manifest.

On the other hand, the Jenkins operator is a Kubernetes native operator which fully manages Jenkins on Kubernetes. It is easy to install with just a few manifests and allows users to configure and manage Jenkins on Kubernetes. To run jenkins-operator, you need to have a running Kubernetes cluster and kubectl installed.

The Jenkins Operator provides out of the box:

  • Integration with Kubernetes — preconfigured kubernetes-plugin for provisioning dynamic Jenkins Slaves as Pods

  • Pipelines as Code — declarative way to version your pipelines in VCS

  • Extensibility via Groovy scripts or Configuration as Code plugin-customize your Jenkins, configure OAuth authorization and more

  • Security and Hardening — an initial security hardening of Jenkins instance via Groovy scripts to prevent security vulnerabilities

In the first month, the focus will be on documenting an introductory section. This section will include but is not limited to Setting up Kubernetes cluster, Installing Jenkins on Kubernetes, exploring the various approaches by which this can be achieved such as using helm package manager or the Jenkins Operator as explained above and Administering Jenkins on Kubernetes.

2nd Month (October - November)

In the second month, the focus will be on documenting how to setup up CI/CD pipelines using Jenkins and Kubernetes on different cloud providers. Some of the cloud providers we will be looking at include but are not limited to:

  • Amazon Web Service (AWS)

  • Azure Kubernetes Service

  • Google Cloud

3rd Month (November - December)

In the final month, the focus will be on creating demos and tutorials, submitting project report, evaluation of mentors and finally, publishing a report of my experience as a participant in Season of Docs.

Conclusion

Jenkins community is actively working towards improving its documentation to create a better experience for Jenkins users and invites technical writers to join the community and contribute to the Jenkins on Kubernetes project.

To contribute to the Jenkins on Kubernetes project, simply join the Jenkins documentation Gitter channel and drop a message, you can also find the Google season of docs office hour notes and recordings for Jenkins on Kubernetes here. GSOD office hours take place twice a week on Mondays and Thursdays between 6pm GMT+1 and 7pm GMT+1, if you would like to be part of these meetings, you can indicate interest in the Jenkins DocumentationGitter channel and we would be happy to have you.

If you are also a newcomer and would like to contribute to Jenkins, documentation is a great place to contribute. A lot of small patches can be done from the GitHub web interface even without cloning repositories locally. You can find some good first issues to get started with here.

Find more information on contributing to Jenkins documentation here. If you have further questions about the Jenkins on Kubernetes project or contributing to Jenkins, you can reach out on the Jenkins documentation Gitter channel.

Additional Resources


Cross-Industry DevOps: 3 Firms Get It Right with Jenkins

$
0
0

Some months ago, we took a significant step in helping the Jenkins community share their stories of how they improved workflows, sped up testing, and saw better quality results after implementing Jenkins into their software development processes.

By the end of the year, we’ll have over 50 Jenkins user stories published with many more in the pipeline. We invite you to explore them all but wanted to share three inspiring examples highlighting how various organizations approach — and implement — Jenkins in the workplace. Enjoy!

Story 1: Jenkins is the way to tackle any challenge

Enterprise-wide CI/CD solution caters to the complex problems that project teams face each day, as told by Jenkins user Mark Baumann:

“Our development teams work in a wide range of projects and domains. We have a very diverse tooling landscape since the projects work with all kinds of different software tools. Of course, projects in the embedded domain will have different toolsets than those working in the automotive domain.

Each project team created its own CI Toolchain, which caused a lot of work for the developers and the IT department. Each project needed to set up their own virtual machine, install and manage their own CI Server, Version Management, and whatever they needed. Creating such a toolchain could easily take up weeks until it was running because there was no standard solution and each team had to start from scratch.”

Discover how ITK-Engineering GmbH developed a company-wide, common, internal CI/CD toolchain and increased the number of builds for each project and how nearly all departments are now practicing CI/CD. The full Jenkins / ITK Engineering story is here!

Story 2: Jenkins is the way to add spicy flavors to agency processes

A creative agency start-up simplifies the build, test, and deploy steps, allowing the small team to focus more on the deliverables and less on the process. As told by Jenkins user Erik Woitschig:

“It was quite a challenge to streamline and combine all the services to build an artifact to deploy. Because of our micro service-oriented and distributed architecture, the most challenging part of rethinking our build, test, and deploy process was to figure out how best to sync the deployment of all services. We also had to retest builds properly to go live or initiate a rollback.

With Jenkins and some pipelines, it was relatively simple to create a local and distributed artifact of our application to quickly share and deploy across the team, locally and globally.”

Because Jenkins is simple to install and easy to maintain, Muzkat has increased productivity far beyond that of a 3-person team. Read on to learn how this bootstrapped Berlin-based agency is making a go of it with Jenkins. The full Jenkins / Muzkat story is here!

Story 3: Jenkins is the way to focus on your code

As demands for the Wright Medical’s services grew, they required an agile DevOps environment that would grow and scale along with the tech team, as told by Jenkins user Christophe Carpentier:

“What was critical to our success was the stability of Jenkins and a significant number of reliable plugins! We could take a few plugins, set up our workflow, and add GitLab and SonarQube integration without ever stopping or losing data in over a year. We found that all of the problems we encountered were our own, and that is why it was critical to make Jenkins an essential part of our workflow.

With this implementation, Jenkins allows more than would be manually possible. It flawlessly updates our staging environments, blocks commits based on the SonarQube analysis, and provides us with near-instant feedback on merge requests.”

Learn how Wright Medical supports a growing dev team by switching to an agile DevOps process that allows for automatic daily releases — versus weekly manual builds. Best of all, it’s letting the developers focus on building great code rather than infrastructure. The full Jenkins / Wright Medical story is here!

What are you building?

Hope you enjoy these Jenkins user stories. You’ll find that “Jenkins Is The Way” website is a global showcase of how developers and engineers build, deploy, and automate great stuff with Jenkins. If you want to share your story, we’ll send you a free Jenkins Is The Way T-Shirt in return. Hope to hear from you soon!

A sustainable pattern with shared library

$
0
0

This post will describe how I use a shared library in Jenkins. Typically when using multibranch pipeline.

If possible (if not forced to) I implement the pipelines without multibranch. I previously wrote about how I do that with my Generic Webhook Trigger Plugin in a previous post. But this will be my second choice, If I am not allowed to remove the Jenkinsfile:s from the repositories entirely.

Context

Within an organization, you typically have a few different kinds of repositories. Each repository versioning one application. You may use different techniques for different kinds of applications. The Jenkins organization on GitHub is an example with 2300 repositories.

The Problems

Large Jenkinsfiles in every repository containing duplicated code. It seems common that the Jenkinsfile:s in every repository contains much more than just the things that are unique for that repository. The shared libraries feature may not be used, or it is used but not with an optimal pattern.

Installation specific Jenkinsfile:s that only work with one specific Jenkins installation. Sometimes I see multiple Jenkinsfile:s, one for each purpose or Jenkins installation.

No documentation and/or no natural place to write documentation.

Development is slow. Adding new features to repositories is a time consuming task. I want to be able to push features to 1000+ repositories without having to update their Jenkinsfile:s.

No flexible way of doing feature toggling. When maintaining a large number of repositories it is sometimes nice to introduce a feature to a subset of those repositories. If that works well, the feature is introduced to all repositories.

The Solution

My solution is a pattern that is inspired by how the Jenkins organization on GitHub does it with its buildPlugin(). But it is not exactly the same.

Shared Library

Here is how I organize my shared libraries.

Jenkinsfile

I put this in the Jenkinsfile:s:

buildRepo()

Default Configuration

I provide a default configuration that any repository will get, if no other configuration is given in buildRepo().

I create a vars/getConfig.groovy with:

defcall(givenConfig = [:]) {def defaultConfig = [/**
      * The Jenkins node, or label, that will be allocated for this build.
      */"jenkinsNode": "BUILD",/**
      * All config specific to NPM repo type.
      */"npm": [/**
        * Whether or not to run Cypress tests, if there are any.
        */"cypress": true
    ],"maven": [/**
        * Whether or not to run integration tests, if there are any.
        */"integTest": true
    ]
  ]// https://e.printstacktrace.blog/how-to-merge-two-maps-in-groovy/def effectiveConfig merge(defaultConfig, givenConfig)
  println "Configuration is documented here: https://whereverYouHos/getConfig.groovy"
  println "Default config: " + defaultConfig
  println "Given config: " + givenConfig
  println "Effective config: " + effectiveConfigreturn effectiveConfig
}

Build Plan

I construct a build plan as early as possible. Taking decisions on what will be done in this build. So that the rest of the code becomes more streamlined.

I try to rely as much as possible on conventions. I may provide configuration that lets users turn off features, but they are otherwise turned on if they are detected.

I create a vars/getBuildPlan.groovy with:

defcall(effectiveConfig = [:]) {def derivedBuildPlan = ["repoType": "NOT DETECTED""npm": [],"maven": []
  ]

  node {
    deleteDir()
    checkout([$class: 'GitSCM',branches: [[name: '*/branchName']],extensions: [
          [$class: 'SparseCheckoutPaths',sparseCheckoutPaths:
            [[$class:'SparseCheckoutPath', path:'package.json,pom.xml']]
          ]
      ],userRemoteConfigs: [[credentialsId: 'someID',url: 'git@link.git']]
    ])if (fileExists('package.json')) {def packageJSON = readJSON file: 'package.json'
      derivedBuildPlan.repoType = "NPM"
      derivedBuildPlan.npm.cypress = effectiveConfig.npm.cypress && packageJSON.devDependencies.cypress
      derivedBuildPlan.npm.eslint = packageJSON.devDependencies.eslint
      derivedBuildPlan.npm.tslint = packageJSON.devDependencies.tslint
    } elseif (fileExists('pom.xml')) {
      derivedBuildPlan.repoType = "MAVEN"
      derivedBuildPlan.maven.integTest = effectiveConfig.maven.integTest && fileExists('src/integtest')
    } else {throwRuntimeException('Unable to detect repoType')
    }

    println "Build plan: " + derivedBuildPlan
    deleteDir()
  }return derivedBuildPlan
}

Public API

This is the public API, this is what I want the users of this library to actually invoke.

I implement a buildRepo() method that will use that default configuration. It can also be called with a subset of the default configuration to tweak it.

I create a vars/buildRepo.groovy with:

defcall(givenConfig = [:]) {def effectiveConfig = getConfig(givenConfig)def buildPlan = getBuildPlan(effectiveConfig)if (effectiveConfig.repoType == 'MAVEN')
    buildRepoMaven(buildPlan);
  } elseif (effectiveConfig.repoType == 'NPM')
    buildRepoNpm(buildPlan);
  }
}

A user can get all the default behavior with:

buildRepo()

A user can also choose not to run Cypress, even if it exists in the repository:

buildRepo(["npm": ["cypress": false
  ]
])

Supporting Methods

This is usually much more complex, but I put some code here just to have a complete implementation.

I create a vars/buildRepoNpm.groovy with:

defcall(buildPlan = [:]) {
  node(buildPlan.jenkinsNode) {
    stage("Install") {
      sh "npm install"
    }
    stage("Build") {
      sh "npm run build"
    }if (buildPlan.npm.tslint) {
      stage("TSlint") {
        sh "npm run tslint"
      }
    }if (buildPlan.npm.eslint) {
      stage("ESlint") {
        sh "npm run eslint"
      }
    }if (buildPlan.npm.cypress) {
      stage("Cypress") {
        sh "npm run e2e:cypress"
      }
    }
  }
}

I create a vars/buildRepoMaven.groovy with:

defcall(buildPlan = [:]) {
  node(buildPlan.jenkinsNode) {if (buildPlan.maven.integTest) {
      stage("Verify") {
        sh "mvn verify"
      }
    } else {
      stage("Package") {
        sh "mvn package"
      }
    }
  }
}

Duplication

The Jenkinsfile:s are kept extremely small. It is only when they, for some reason, diverge from the default config that they need to be changed.

Documentation

There is one single point where documentation is written, the getConfig.groovy-file. It can be referred to whenever someone asks for documentation.

Scalability

This is a highly scalable pattern. Both with regards to performance and maintainability in code.

It scales in performance because the Jenkinsfile:s can be used by any Jenkins installation. So that you can scale by adding several completely separate Jenkins installations, not only nodes.

It scales in code because it adds just a tiny Jenkinsfile to repositories. It relies on conventions instead, like the existence of attributes in package.json and location of integration tests in src/integtest.

Installation Agnostic

The Jenkinsfile:s does not point at any implementation of this API. It just invokes it and it is up to the Jenkins installation to implement it, with a shared libraries.

It can even be used by something that is not Jenkins. Perhaps you decide to do something in a Docker container, you can still parse the Jenkinsfile with Groovy or (with some magic) with any language.

Feature Toggling

The shared library can do feature toggling by:

  • Letting some feature be enabled by default for every repository with name starting with x.

  • Or, adding some default config saying "feature-x-enabled": false, while some repos change their Jenkinsfile:s to buildRepo(["feature-x-enabled": true]).

Whenever the feature feels stable, it can be enabled for everyone by changing only the shared library.

2020 Elections: Governance Board and Officer candidates

$
0
0
Jenkins 2020 Elections are over, thanks to all participants! Please see the results announcement .

As you probably know, in a few weeks we will have the Jenkins 2020 elections. We will be electing two governance board members and five officers, namely: Security, Events, Release, Infrastructure, and Documentation. After the announcement on Sep 24, we have been accepting nominations from community members.

After the processing and confirmations with potential candidates, the Jenkins 2020 Elections committee is happy to announce the candidates for the Jenkins Governance Board and Officer roles:

  • Governance Board candidates: Andrey Falko, Ewelina Wilkosz, Frederic Gurr, Gavin Mogan, Justin Harringa, Mark Waite, Marky Jackson, Steven Terrana, Zhao Xiaojie (Rick)

  • Release officer: Baptiste Mathus, Tim Jacomb, Victor Martinez

  • Security officer: Daniel Beck (uncontested)

  • Events officer: Marky Jackson (uncontested)

  • Infrastructure Officer: Olivier Vernin (uncontested)

  • Documentation officer: Mark Waite (uncontested)

We encourage all community members to support the candidates and to participate in the elections!

register button

Key dates

  • Nov 10 - Voting begins. Condorcet Internet Voting Service will be used for voting.

  • Nov 24 - Voting sign-up is over.

  • Nov 27 - Voting ends, 11PM UTC.

  • Dec 03 - Election results are announced and take effect.

Signing up for voting

Any Jenkins individual contributor is eligible to vote in the election if there was a contribution made before September 01, 2020.Contribution does not mean a code contribution, all contributions count: documentation patches, code reviews, substantial issue reports, issues and mailing list responses, social media posts, testing, etc. Such a contribution should be public.

You can register to vote in one of two ways:

  1. Fill out this Google Form. This way requires logging into your Google Account to verify authenticity.

  2. Send an email to jenkins-2020-elections@googlegroups.com. You will need to provide the information specified here.

Once sign-up is over, the election committee will process the form submissions and prepare a list of the registered voters. In the case of rejection, one of the election committee members will send a rejection email. Every individual contributor is expected to vote only once.

Candidates

Below you can find statements, affiliations and profile links provided by the candidates.

Minimum copy-editing was applied to the content by the Jenkins 2020 Elections Committee. Candidates are sorted by the first name.

Governance Board

Andrey Falko

I have been a Jenkins user and administrator on and off since around 2010. In 2016, I got into evangelism by organizing aJenkins Area Meetup in San Francisco. I spoke at Jenkins World 2017  and again at Jenkins World 2018. Justin Harringa and I wrote and open sourced the Config Driven Pipeline Plugin. For two years running, I’ve been a mentor for two Google Summer of Code projects: External Fingerprint Storage Project and Remoting over Apache Kafka with Kubernetes features.

With this nomination, I hope to continue helping strengthen and progress the community further. As a member of the governance board, I’ll bring a fresh perspective by asking questions, providing feedback, and finding opportunities for others to contribute.

Profile links:GitHub,LinkedIn

Affiliations: Stripe

Ewelina Wilkosz

As a consultant I support my customers with their Jenkins issues since the beginning of 2017. And almost from the start it was some kind of "as code" approach. The experience I gained during that time resulted in getting myself involved in the development of Configuration as Code Plugin for Jenkins. I consider becoming a part of Jenkins Community one of the most valuable experiences in my career so far. I appreciate how much I have learned and how welcoming the community is.

I am not a very active contributor these days, at least when it comes to code, but what I have to offer is rather extensive experience with Jenkins end users - from small, single instance setups to environments with hundreds of controllers run in a different way on different operating systems. Every day I see challenges those users go through, I know what issues they are facing and which features they consider valuable or missing. As a Jenkins Governance Board Member I can represent those users.

Thanks to my involvement in Configuration as Code Plugin development I had a chance to deliver a number of public presentations where I focused on the benefits of the solution and tried to make it easier for newcomers to try it. Here are a few examples of my activities related to Jenkins Configuration as Code:blogpost,cdCON presentation,podcast recording. So my focus is not only on representing users but also on educating them, and educating myself, so I actually know what they need and why.

Profile links:GitHub,LinkedIn,Twitter

Affiliations: Eficode (former Praqma)

Frederic Gurr

I started to use Jenkins back in 2008, when it still had a different name. In 2011 I started to contribute and created my first little plugin calledextra-columns. Since then, using and administering Jenkins servers has become a major part of my work life, while getting involved with the Jenkins community kickstarted my interest and involvement with open source software and communities.

I’ve been working as a release engineer at the Eclipse Foundation since 2016, supporting 250+ Jenkins instances for various open source projects. I’d be honored to bring a user and admin oriented perspective to the Governance Board and help shape the future of Jenkins.

Profile links:GitHub,Twitter

Affiliations: Eclipse Foundation

Gavin Mogan

I got started with Jenkins early on when I was just getting started with testing. I knew there had to be a way to run the tests automatically and report on them back to people. I started hacking my own tools before I came across Jenkins (then Hudson) and was hooked ever since. Over the years I’ve managed to install and configure Jenkins at various jobs, and even was employed making internal and external plugins and integrations. You’ll often find me on the Jenkins IRC and Gitter channels as well as the subreddit giving a hand to people who are stuck. I also try to get involved with Jenkins Infrastructure projects as much as I can. I currently maintain the plugin site, plugin site API, Jenkins Wiki exporter, and a bunch of other minor projects. I also help run Vancouver’s chapter of Nodeschool.

If elected, I would like to address improving commercial support avenues. Right now it’s a lot of people flailing in isolation. I would like to not only improve things so people can find easier ways to get help, but also encourage more users to help others, and push for a centralized source of companies providing commercial support.

Profile links:GitHub,Twitter

Affiliations: Digital Ocean, Nodeschool Vancouver

Justin Harringa

The nomination is quite an honor for me. I have been a Hudson/Jenkins user since around 2009/2010 when I started working through driving continuous integration in a corporate environment at John Deere. As time went on, I began contributing some small fixes to plugins such as the Job DSL Plugin, OpenID Plugin, and the Workflow Job Plugin. Eventually, I ended up helping maintain Salesforce’s Chatter plugin and then open sourcing plugins such as the Config-Driven Pipeline Plugin with Andrey Falko. More recently, I have also had the extreme pleasure of mentoring in 2 Jenkins projects for Google Summer of Code (Multi-branch Pipeline support for Gitlab in 2019 and Git Plugin Performance Improvements in 2020).

I have learned so much from working with Jenkins and I would love to give back to the project further. Having introduced Jenkins at both small and large companies, I would love to help contribute to the direction of the project through the Roadmap/SIGs/JEPs and encourage others to also contribute / improve Jenkins.

Profile links:GitHub,Twitter,LinkedIn

Affiliations: Salesforce, Spinnaker SIG for Azure

Mark Waite

I’m a Jenkins contributor, a member of the Jenkins core team, one of the leaders of the Platform Special Interest Group, and leader of the Documentation Special Interest Group. I’ve served as the Jenkins Documentation Officer since 2019. I was a mentor for Google Season of Code 2020 and am one of the maintainers of the Git plugin for Jenkins.

If elected and allowed to serve on the Jenkins Board, I’ll work to increase community involvement and community development. I’m deeply interested in tooling and environments that support the Jenkins project, including the Jenkins CI environments, issue tracker, artifact repository, and source code repositories.

Affiliations: CloudBees

Marky Jackson

I have been involved in the Jenkins project for many years. I started out as a plugin maintainer, SIG member and general helper. I moved to a SIG lead, speakers and Google Summer of Code and Docs org admin and mentor. My current goals are to help continue the work of the public roadmap as well and gain most community members by continuing to be a champion of the community.

For me, being on the Jenkins Board is another opportunity to improve upon the great work we have all done as well as work toward branching out our efforts to have more women, people of color and LGBTQIA members. I would be honored to have this opportunity.

Affiliations: Equinix Metal, Continuous Delivery Foundation, Kubernetes, Ortelius

Steven Terrana

I have been a Jenkins user since 2017 and contributor since 2018. I am the primary maintainer of the Jenkins Templating Engine, a plugin that allows users to create truly templated Jenkins pipelines that can be shared across teams. Through that work, I’ve had the great pleasure of helping to organize the Pipeline Authoring Special Interest Group, contributing to the Jenkins Pipeline documentation, and contributing bug fixes to various plugins (including the pipeline plugin and workflow-cps library).

As a Continuous Delivery Foundation Ambassador, I’ve enjoyed doing what I can to advance the community’s approach to CI/CD and simplifying DevSecOps adoption within large organizations. It would be a privilege to serve on the Jenkins Governance Board and offer my support wherever I can.

Profile links:GitHub,LinkedIn

Affiliations: Booz Allen Hamilton, Continuous Delivery Foundation

Zhao Xiaojie (Rick)

Three years ago I joined the Jenkins community. I learned a lot during the process of contributing. I even became a Jenkins hero in my city. The most exciting thing I want to do is help more new users of Jenkins get started, and let more contributors feel comfortable. I always love to host a JAM no matter if it’s online or offline.

Plans: improve the experience of using Jenkins in different countries; reorganize the knowledge of Jenkins, for example the tutorial by text or video format; help other SIG leaders to organize meetings.

Profile links:GitHub,Twitter

Affiliations: N/A

Release Officer

Baptiste Mathus

I have been using and contributing to Jenkins for so long that it is difficult for me to check when it started exactly. My first pull-request to Jenkins was in 2011 and I had started to use it long before it. Throughout the years, I have contributed to various areas: created our local Jenkins Area Meetup with Michaël Pailloncy, helped users and developers on our mailing lists and IRC channels, contributed to the Jenkins infrastructure, the website, processing plugins hosting requests, worked full time on Jenkins Evergreen, and I am still present today.

For all these reasons, it would be an honor to serve as the Release Officer for the Jenkins Project.

Affiliations: CloudBees

Tim Jacomb

I have been a user of Jenkins for the last 8 years and a regular contributor since 2018. I began with maintaining the Slack plugin and over the last couple of years I have since expanded that to many more plugins and the Jenkins core. These are some of the components I maintain when I have time: Slack, Azure Key Vault, Junit, most of the Database plugins, Dark theme, Plugin installation manager, Jenkins Helm chart, Configuration as code plugin. I am also a member of the Jenkins infrastructure team, and I was involved in the release automation project and the mirrors modernisation effort, along with the day to day support helping people regain access to accounts etc.

As a Release Officer I would like to increase automation, ease onboarding of new contributors to the release team, and ensure that responsibilities rotate among people so that I wouldn’t be a bottleneck for any task.

Profile links:GitHub,Jenkins Blog

Affiliations: Kainos

Victor Martinez

I have been involved in the Jenkins project since 2011 by different means, as a user, as an administrator, as a contributor (bug reporting, plugin development, documentation, hackfest), being active in the different Jenkins forums such as the Jenkins-dev and Jenkins-user mailing lists, working with the jenkins-infra shared library and so on. I’m also an advocate for the Jenkins project through some presentations anytime that I had the opportunity such as DevOps World 2020 and Jenkins World 2017.

I’ve been happily nominated for the Release officer role which matches not just my area of professional expertise that I’ve been doing for the last 14 years in different roles for different companies but also that’s an area of personal interest where I’d like to spend time with the Jenkins community to understand, document and automate the process in a way we can keep the project sustainable for a long term as it’s today, it’s not just about what I can bring for the community but also about growing together.

If elected as a Release officer I would aim to focus on the following areas: proceed with the existing responsibilities for this role; document and automate the release process; being an enabler for the Continuous Delivery not just for the plugins but also for the core.

Profile links:GitHub,LinkedIn

Affiliations: Elastic

Security Officer - uncontested

Daniel Beck

I’ve been a Jenkins user since 2011, contributor since 2013, and core maintainer since 2014. In 2015, I took on the scheduling and authoring of security advisories and have been doing that ever since, working with reporters, maintainers, and the Jenkins security team to deliver security fixes. Beyond that, I regularly contribute to Jenkins and project infrastructure.

Since I’ve started in the Security Officer role, we’ve made significant improvements: Plugins no longer allow ordinary users to run arbitrary scripts (no sandbox!) as a regular feature. I introduced fine-grained permission managementfor our GitHub repositories and the Maven repository hosting our releases.Warnings directly in Jenkins inform admins when an installed component has known security issues (and their UX was improved earlier this year). The Jenkins project  is now a CVE Numbers Authority, to ensure timely and high-quality information in the CVE vulnerability database. Working with Tyler, I added telemetry to Jenkins, which allowed us to deliver multiple large-scale security fixes withminimal impact. More recently, I’ve started writing code scanning rules for common problems in Jenkins and invited maintainers to sign their plugins up, which is something I hope to properly publish and roll out more widely soon.

Profile links:GitHubJenkins Blog

Affiliations: CloudBees

Events Officer - uncontested

Marky Jackson

I have been a part of the Jenkins community for some time, and I have received the utmost joy in volunteering. I have been extremely fortunate to have played a lead role in the Outreach & Advocacy SIG, the pipeline-Authoring SIG, and, most recently, the Cloud-Native SIG. I have taken part in many meetups, org admin, and mentor in the GSoC & GSoD. Finally, At DevOps World 2020, I received Jenkins most valuable advocate at DevOps World. I have experience advocating in other communities as well: Kubernetes Release Manager Associate, Kubernetes Mentoring Lead, Ortelius Community Manager.

Jenkins is the most widely used Continuous Integration tool around, and I want to continue to promote that by focusing on the following areas: meetups; conference presentation from the Jenkins community; new user outreach and onboarding; cross-community collaboration (e.g., Kubernetes community); working with the Continuous Delivery Foundation on interoperability; focusing on SIG events.

My roots are open-source, and I am so proud to be a part of the Jenkins community. You can read more about my journey in open-source here. You can also see some of my presentations here andhere.

Affiliations: OpsMx, Continuous Delivery Foundation, Kubernetes, Ortelius, Spinnaker

Infrastructure Officer - uncontested

Olivier Vernin

I have been actively contributing to the Jenkins project for the past four years with contributions across many areas, and infrastructure is one of my favorite topics. Over my previous mandate as a Jenkins infrastructure officer, I focused on improving contribution experience, and let community members opportunities to take ownership of the different services. I worked on various sponsoring initiatives to make the Jenkins infrastructure more sustainable. We provided a new environment for releasing Jenkins core (and one plugin!), and also many more things.

For the coming year, It is hard to make commitments on what it will look like as we have things we know, like services that need some attention (“ci.jenkins.io/) and the things we don’t know yet. Anyway, It’s important to me to have a transparent project where everybody could read, learn, participate, and understand how the Jenkins project manages infrastructure and I want to continue down that path.

Affiliations: CloudBees

Documentation Officer - uncontested

Mark Waite

I’m a Jenkins contributor, a member of the Jenkins core team, one of the leaders of the Platform Special Interest Group, and leader of the Documentation Special Interest Group. I’ve served as the Jenkins Documentation Officer since 2019. I was a mentor for Google Season of Code 2020 and am one of the maintainers of the Git plugin for Jenkins.

If elected and allowed to serve as Documentation Officer, I’ll continue efforts to invite more contributors through regular Documentation Office Hours and outreach programs like Google Season of Docs, CommunityBridge, Outreachy, and Jenkins Hackfests. I’ll work to assure an inviting and welcoming environment for contributors.

Affiliations: CloudBees

First results from using GitHub CodeQL to discover security vulnerabilities in Jenkins plugins

$
0
0

A little over a month ago, GitHub announced the general availability of its code scanning solution. It’s based on CodeQL, which makes it pretty easy to write queries for it and run them using the CodeQL GitHub action, CodeQL command line tools, or on lgtm.com.

Many of the security vulnerabilities discovered in Jenkins plugins are fairly similar to each other, and unfortunately they’re usually specific to Jenkins, which means existing generic tools would not be able to discover them. So I decided to write CodeQL queries for Jenkins-specific issues and invited maintainers to sign their plugins up for a "private beta" of code scanning for these issues.

Today’s security advisory is the first one that includes findings discovered through that initiative. All these issues were discovered with assistance by this tooling:

While there were of course also false positives we had to review and mark as ignored, the integration with the GitHub UI made this pretty straightforward. Overall I’m very happy with the results so far, especially considering how new this initiative is.

Interested in making the plugin you are maintaining more secure? Sign up now by filing an INFRA issue in the github component and list the plugin repositories you’d like to have scanned.

Document Jenkins on Kubernetes: Installing Jenkins on Kubernetes Documentation Release

$
0
0

We are super excited to announce that the Document Jenkins on Kubernetes Project recently merged its first PR into Jenkins.io. This PR adds a new Kubernetes section to the existing Installing Jenkins chapter of Jenkins.io.

Installing Jenkins on Kubernetes Section

This new section describes two options to install/run Jenkins on Kubernetes, how to setup a minikube cluster on which to run your Jenkins deployment and finally a bonus segment that explains some Post-installation setups such as unlocking Jenkins, customizing Jenkins with plugins and creating your first administrator user.

The first installation option covered in this section is helm a package manager for Kubernetes whose package format is called a chart. The helm section covers the prerequisites for installing Jenkins on Kubernetes using Helm, installing and configuring helm, creating a persistent volume and service account, and finally, Installing Jenkins.

The second option describes how to install Jenkins using a set of yaml files. This section explains how to create a Jenkins deployment file, Deploy Jenkins, grant access to jenkins service, and finally access your Jenkins dashboard after installation.

Splitting the Installing Jenkins Chapter

The addition of the Kubernetes section highlighted a long-standing challenge with the Installing Jenkins chapter. It was too long and contained too many topics, making it difficult and unpleasant for most users to navigate. To top the icing on the cake and further improve the experience on Jenkins documentation users, another PR was merged into Jenkins.io to split the Installing Jenkins chapter into smaller chapters for better separation of concerns and easy navigation. This PR also redirects bookmarks that linked to the previous locations like https://www.jenkins.io/doc/book/installing/#debianubuntu using Javascript.

Installing Jenkins chapter before the PR

The image above is a snapshot of what the Installing Jenkins chapter looked like before the PR. All sections of this chapter such as docker, Kubernetes and others were lumped up on the same page making it too long with so much information thereby making it difficult to navigate or even find information on this page.

Installing Jenkins chapter after the PR

This snapshot shows what the Installing Jenkins chapter looks like after the PR. With this chapter split into smaller sections, it’s neater, clearer and most importantly easier to navigate to the section of interest without having to scroll through so much information that’s not necessarily needed.

Testing, Participating and Contributing

The Jenkins Community invites the general public to try out these documentation updates and give feedback to help us further improve the documentation. If you have any feedback, suggestions, or would like to contribute to the Jenkins on Kubernetes project, drop a message indicating your interest in the Jenkins documentation Gitter channel. You can also find the Google season of docs office hour notes and recordings for Jenkins on Kubernetes here. GSOD office hours take place twice a week on Mondays and Thursdays between 6 pm GMT+1 and 7 pm GMT+1, if you would like to be part of these meetings, you can indicate interest in the Jenkins Documentation Gitter channel and we would be happy to have you.

Spring and XStream updates (breaking changes!)

$
0
0

Cleaning up technical debt is a perennial topic among Jenkins core developers, and one of the most visible issues is the use of obsolete and/or forked third-party libraries. In a world where Dependabot is offering updates to libraries released just hours before, it is unpleasant to be working with dependencies that are many years old. Since large organizations in particular are unhappy to install software using obsolete or nonstandard versions, my employer (CloudBees) gave its blessing for me to spend some time cleaning up some of the worst offenders.

The toughest nut to crack was the Acegi Security library used for authentication, which has long since been replaced by Spring Security (and Jenkins was also bundling a long-outdated version of some Spring Framework dependencies).JEP-227 tracks the complicated task of updating to Spring Security without breaking the numerous plugins that interact with authentication, especially those offering a Security Realm.

Another longstanding problem was the XStream library which Jenkins uses to read and write XML configuration files. This had been forked long ago by what was then the Hudson project and a few fixes applied. Unfortunately, some of those fixes were rejected upstream as invalid (representing unsupported usage patterns), and the fork fell behind the upstream version.JEP-228 describes the impact of switching to the upstream library in a more standard usage mode, including fixes to a smaller number of plugins which would otherwise be incompatible.

Now that the Jenkins 2.266 weekly release includes both updates, it is important for both Jenkins administrators and plugin maintainers to check for actual or potential incompatibilities. There are two tables listing the impact of these changes on plugins:

If you use Jenkins then it is a good idea before upgrading to take a look at these tables to see if you are running any plugins considered incompatible. If so, try not to rely on that plugin, or find out if there is an active maintainer who could help. For entries marked unknown, it would be appreciated if you could do a sanity check after upgrading and offer a pull request to the table page (click Edit this file) with a more informative status.

If you find a regression in a plugin, please file a bug report in Jira and link to it from the table. Also please add a JEP-227 or JEP-228 label as appropriate, for ease of tracking:

It is a good idea to update all your plugins before upgrading Jenkins core. In the case of the Spring Security update, some security realm plugins including LDAP and Active Directory must be updated in advance. (You can safely run the new plugin versions on Jenkins releases prior to this change.) Otherwise, you risk being unable to log in to Jenkins—and thus unable to update those plugins from the GUI! The LDAP plugin additionally has a new version available only after the core upgrade, but there is no rush in switching to that.

If you maintain a Jenkins plugin then please check whether it is marked anything less than compatible. In some cases, there are already pull requests awaiting merge. In other cases, some minor aspects of the source code have been identified that could be edited to improve compatibility.

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.

Jenkins 2.264+: Major changes in the weekly release line

$
0
0

Recently we have selected Jenkins 2.263 as a new baseline for the LTS release line, with ETA in December 2020. It allows delivering significant and in some cases breaking changes which have been previously on hold. Beginning with the Jenkins 2.264 release on October 27, 2020, we’ve entered a period where the Jenkins weekly releases will include more significant changes than usual. That period of more significant changes is expected to continue for a month or more. As you may have seen from the release community ratings, there might be regressions and instabilities during this period.

We’re excited for the changes. They help to improve user experience and to address the technical debt accumulated in the Jenkins core. We invite Jenkins users to evaluate those changes and provide feedback. This is an especially valuable time for users and administrators to test the weekly releases and report issues with them, especially on Jenkins test environments. In the Jenkins project we have invested a lot in test coverage for the main functionality, but in many cases we rely on user feedback for exotic plugins and environments not yet covered by our test automation.

The most notable changes include:

Configuration UI - Tables to Divs

Jenkins 2.264 is the first weekly release to include the "Tables to Divs migration" user interface work of Josh Soref, Tim Jacomb, and Felix Queiruga. It is a significant step to improve forms in the Jenkins user interface (configuration pages, build parameters, etc.), especially for users on narrow devices like tablets and phones.

A better user interface

The transition from using HTML table tags to using HTML div tags provides a more attractive user interface for all users and a much better experience for users on narrower devices. Before the conversion from table tags to div tags, the "Manage Jenkins" page looked like this in a 1024x768 window:

Before the pull request

After the conversion, the "Manage Jenkins" page now looks like this:

After the pull request

The user interface improvements from the transition are a nice step forward for Jenkins. However, because the user interface improvements require changes in plugins, we need your help.

We need users to test the latest weekly Jenkins releases with the plugins and configurations that are most important to them. When users detect an issue, we need them to report the issue with enough detail that a plugin maintainer can fix the issue. Please add the tables-to-divs-regression label to the issues. The tables-to-divs-regression label makes it easier to find issues related to the tables to divs transition.

Plugin developers

Several plugins have already been identified that may need changes. See the Jira epic for plugins that are likely to need changes for the new user interface layout. The list of open tables-to-divs-regression issues can also be used to see plugins that need changes.

If you can assist with plugin testing and code changes, select one of the plugins from that epic, test it, and propose a pull request to help with this user interface transition. If you’re not comfortable proposing a pull request, describe the problems you see in a bug report.

A tables to divs migration guide is available. It describes areas that typically need to be changed as part of the migration from tables to divs. It also includes detailed examples that allow the plugin to continue supporting older Jenkins versions with table layouts and use div layouts for newer Jenkins versions.

Core - Spring Security replaces Acegi Security

The Jenkins 2.266 release on November 10, 2020 will include the migration to the Spring Security libraries from the Acegi security libraries that Jesse Glick has proposed and developed through JEP-227: Jenkins Enhancement Proposal 227.

This upgrade replaces the Acegi Security library with the current release of the Spring Security library. Details of the change are described in JEP-227 and in the pull request.

We need users to test the latest Jenkins weekly releases with their plugins and watch for issues related to authentication.

Refer to Jesse Glick’s blog post that introduces the details of the change and provides links to the Spring Security compatibility table. Jesse’s blog post provides specific instructions for those who report bugs related to this change. Please use those instructions as you submit bug reports related to the Spring Security upgrade.

Core - XStream unfork

Jenkins has been using a fork of the XStream serialization library to read and write XML files. The XStream library was forked over 10 years ago and had a few fixes applied to it. Unfortunately, at that time the fixes were rejected by the upstream maintainers of XStream (unsupported patterns of API use) and the fork fell behind the upstream version.

The Jenkins 2.266 release on November 10, 2020 will include the migration to the upstream version of the XStream library that Jesse Glick has proposed and developed through JEP-228: Jenkins Enhancement Proposal 228.

Refer to Jesse Glick’s blog post that introduces the details of the change and provides links to the XStream compatibility table. Jesse’s blog post provides specific instructions for those who report bugs related to this change. Please use those instructions as you submit bug reports related to the XStream upgrade.

UI - JQuery upgrade

Jenkins uses a 1.x version of the jQuery user interface library for some of its components.Felix Queiruga has started the work to update that library to a current jQuery version.

It will arrive in a future Jenkins weekly release. When it arrives, it will be noted in the Jenkins weekly changelog.

When the jQuery update arrives, We will need users to test the Jenkins weekly release with the plugins and configurations that are most important to them. When users detect an issue, we need them to report the issue with enough detail that a plugin maintainer can fix the issue.

Call to test

This is a great time to help the Jenkins project by testing the weekly releases. We encourage you to test the user interface and the interactions that are most important to you. If you find an issue, please report the issue so that others can benefit from your discovery.


2020 Jenkins Board and Officer Elections Results

$
0
0

Jenkins Elections

The Jenkins community has recently completed the 2020 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. If you are interested to learn more, please see the blog post below.

Governance Board election details

This year we had nine candidates participating in Jenkins Governance Board elections: Andrey Falko, Ewelina Wilkosz, Frederic Gurr, Gavin Mogan, Justin Harringa, Mark Waite, Marky Jackson, Steven Terrana, and Zhao Xiaojie (Rick). 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. Marky Jackson loses to Mark Waite by 48–12

  3. Gavin Mogan loses to Mark Waite by 51–10, loses to Marky Jackson by 31–20

  4. Ewelina Wilkosz loses to Mark Waite by 48–14, loses to Gavin Mogan by 29–28

  5. Justin Harringa loses to Mark Waite by 51–11, loses to Ewelina Wilkosz by 35–16

  6. Steven Terrana loses to Mark Waite by 47–16, loses to Justin Harringa by 20–19

  7. Zhao Xiaojie (Rick) loses to Mark Waite by 57–5, loses to Steven Terrana by 25–24

  8. Frederic Gurr loses to Mark Waite by 52–10, loses to Zhao Xiaojie (Rick) by 25–24

  9. Andrey Falko loses to Mark Waite by 56–6, loses to Frederic Gurr by 26–13

Although Mark Waite came first in the voting results, being on the board would violate the Corporate Involvement clause which states that "the number of board members affiliated with one company must be less than 50%". Mark will continue to be Documentation officer. Regardless of his official role, Mark has been leading many initiatives and helping a lot with various aspects of the community governance.

Congratulations to Marky and Gavin, and thanks to all candidates! 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. We would also like to thank Alex Earl and R. Tyler Croy who step down from the Jenkins Governance Board this year. Thanks to them for all contributions and for continued community leadership.

Statement from Marky Jackson:

It is a tremendous honor to be elected to this roles. I am so humbled. Being part of this community is a fantastic opportunity that I have had. It has given me so many joys. Whether helping to foster community collaboration, working on the roadmap, leading various SIG’s or helping meetups or conferences, this community has given me so much. My goals are bridging the Jenkins project with other interoperability projects, defining the roadmap, achieving roadmap goals, continuing to help meetups thrive, and our conferences focus on the community. I want to ensure we are transparent in our goals and how we achieved them. I want to continue to build up a welcoming community that holds diversity and inclusion at the forefront. I look forward to working with the other members of the Governance Board to continue to deliver on the incredible things this project is known for.

— Marky Jackson, Jenkins Governance Board Member and Events Officer

Statement from Gavin Mogan:

Gavin here. I’m still in shock that I got voted in for the Jenkins board. It felt like yesterday I just got started helping people randomly on IRC. This is truly exciting. I plan to continue to help out as much as I can wherever I can, just in a bit more official capacity. This is truly exciting. I have no firm plans or agenda, just keep pushing advocacy and getting people to help each other in a positive and safe way. My specialities lie in outside of Jenkins core, whether it be working on the plugin site, or hanging out on IRC, Gitter and Reddit helping out where I can.

— Gavin Mogan, Jenkins Governance Board Member

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, 2021. 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.

Release Officer election results

Tim Jacomb won the biggest support as a Release officer (voting results). Tim will replace in this role Oliver Gondža who has been leading the Release Team and the release processes since 2016 when the role was officially introduced.

  1. Tim Jacomb (Condorcet winner: wins contests with all other choices)

  2. Baptiste Mathus loses to Tim Jacomb by 40–23

  3. Victor Martinez loses to Tim Jacomb by 38–25, loses to Baptiste Mathus by 32–31

Here is a statement from Tim Jacomb:

I’m excited for the year ahead, let’s see where we can take the Jenkins release area in the future. As a Release Officer I would like to increase automation, ease onboarding of new contributors to the release team, and ensure that responsibilities rotate among people so that I wouldn’t be a bottleneck for any task.

— Tim Jacomb, Jenkins Release Officer

Thanks to Alyssa Tong and Oliver Gondža for their long-time service as Jenkins officers! We are looking to continue working with them in the Jenkins community. And congratulations to Tim Jacomb and Marky Jackson for joining the team!

Statistics

This year we had 92 registered voters and around 65 actual votes. It is significantly lower than in the 2019 elections when we had almost 350 voters. It can be partially explained by the change of the communication process. This year we decided to not use the previous voter registration system, and we relied on the user and developer mailing lists instead of sending messages to the entire LDAP user database. This is definitely something we need to review at the retrospective.

What’s next for the board?

The last year was awesome for the Jenkins project governance. With help of many contributors and with the renewed board, we have been able to facilitate many initiatives in the Jenkins project, for example hosting contributor summits, publishing the public roadmap,Code of Conduct update,terminology changes, and graduation in the Continuous Delivery Foundation. There is a lot more work to do to grow the community and to ensure the long term sustainability of the project.

In short term, our key priority is to organize knowledge and permission transfers to the new board members and officers so that they can be effective in their new roles. The board will also focus on maintaining the Jenkins governance processes (meetings, budget approvals, funding, etc.) and defining the next steps and priorities.

There are many longer-term initiatives the board could facilitate: long-anticipated features and architecture changes, changing the Jenkins Enhancement Proposal process, creating better communication channels with Jenkins users, and onboarding of new contributors and maintainers. Such initiatives are instrumental for the evolution of the Jenkins project. The ideas will be discussed in mailing lists and during governance meetings. If you would like to share your vision and ideas about what’s needed in the project, it is definitely a great time to contribute!

Feedback

Jenkins project plans to conduct elections every year. We will appreciate and welcome any 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. There will be also a public retrospective review at the next Advocacy and Outreach SIG meeting on Dec 17.

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.

GSOD Project Report: Document Jenkins on Kubernetes

$
0
0

Jenkins is the world’s leading open-source automation server used by companies large and small around the globe to implement continuous integration and continuous delivery. Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. Kubernetes is compatible with the majority of CI/CD tools which allow developers to run tests, deploy builds in Kubernetes and update applications with no downtime. One of the most popular CI/CD tools now is Jenkins thereby making Jenkins on Kubernetes a popular theme for Jenkins users.

During the Google Season Of Docs program, I worked with the Jenkins organization on the project - Document Jenkins on Kubernetes. The original proposal for this project can be found here.

Project Goals

After my proposal was accepted by the Jenkins organization, my mentors and I agreed on the expectations for the Google Season of Docs project. The goal of this project was to create a new Kubernetes Volume which would describe the concepts, techniques, and choices for Kubernetes users running Jenkins thereby providing the following advantages:

  • Improve the user experience of Jenkins on Kubernetes users by giving them a one-stop-shop for information on Jenkins on Kubernetes.

  • Make it easy to track, update and maintain information on Jenkins on Kubernetes

  • Reference the existing community documentation for Jenkins on K8s (plugins and tools/integrations).

  • How to guides, tutorials and explanations of concepts and techniques in Jenkins on Kubernetes.

  • Just-In-Time documentation which means that rather than documenting every feature comprehensively, we produce and release documentation in bits but continuously based on popular questions, feedback and area of interests gathered from the community and users.

Community Bonding: Planning the solution

Find below an outline of my activities during the community bonding phase:

  • Setting up communication channels: meetings, mailings, chats: My mentors and I agreed on the right time and channel for communication due to time difference. We agreed to meet twice weekly, on Mondays and Thursdays at 7:00 PM GMT +1 and use Jenkins documentation gitter channel for other communications.

  • Contacting Stakeholders and onboarding contributors: The project was announced on social media and different Jenkins channels. I wrote a blog post to announce the project and created a project page on Jenkins.io.

  • Knowledge transfer: I and my mentors planned knowledge sharing sessions and fixed tentative dates based on the availability of the trainers. My mentors also shared useful resources to help me prepare for the project.

  • Getting permissions: I and my mentors agreed I didn’t need any special permissions from the beginning, however, this topic was left open for discussion if the need arose later on in the project.

  • Pre-planning of the project: I refined my goals and set expectations with my mentor and also learned more about the community(Jenkins). I also had to ensure that the proposed documentation structure I drafted was in line with the goals of the organization so my mentors vetted it and we finalized on the proposed sections that I was supposed to work on.

Documentation Development Phase

Knowledge Sharing Sessions

During the development phase, my mentors hosted two knowledge sharing sessions:

Katacoda and Helm by Marky Jackson

See the slides

Helm by Torsten Walter

See the slides

These sessions gave me an in-depth understanding of concepts and tools needed for the project.

Jenkins on Kubernetes Documentation Skeleton

At the application phase, I drafted a structure describing the proposed Jenkins on Kubernetes section. My intention was to use it as a guide during the implementation phase of the project, but when the development phase kicked off, my mentors and I thought of a better approach to creating a new Jenkins on Kubernetes section which was to add the Jenkins on Kubernetes contents to existing related sections for easier navigation and better user experience. An example of this approach would be creating the Installing Jenkins on Kubernetes section under the Installing Jenkins section rather than putting it under an entirely new section. With this new approach, I was assigned a task to create a skeleton with all the proposed Jenkins on Kubernetes sections on Jenkins.io and mark these sections as Work In Progress (WIP). The Plan was to use this skeleton as a guide throughout the GSOD Project. The Jenkins on Kubernetes skeleton PR can be found here.

Documenting Jenkins on Kubernetes

While working on this project, I had to do a lot of research and test all the documented steps locally before pushing the documentation out for review. I also made sure to use updated terms and terminologies where necessary like Controller instead of Master and Agents instead of Slave.

During the documentation phase, I was able to work on documenting Installing Jenkins on Kubernetes with three sections Helm, Set of Yaml files and Jenkins Operator. I also worked on creating a directory for Jenkins on kubernetes sample files in Jenkins.io repository, documenting Scaling Jenkins on Kubernetes and Jenkins on AWS which is still in progress.

Work Done

Pull Requests: All the pull requests I submitted to Jenkins.io documentation can be found here. This spreadsheet contains links to the published documentation on Jenkins.io. The spreadsheet also highlights the initial proposed tasks and the status of each of them.

If you would like to contribute to the Jenkins on Kubernetes documentation, you can check out pending tasks here and reach out in the Jenkins documentation gitter channel.

Challenges

Using a Windows computer was a bit of a challenge for me. To run Jenkins.io locally, the project uses GNU/Make and Docker in order to generate the fully statically generated jenkins.io web site. The key tool for converting source code into the site is the Awestruct static site generator, which is downloaded automatically as part of the build process. To achieve this, I needed to have GNU/Make and Docker available on my machine. Docker was not a problem, but to achieve the latter, I needed to use Windows Subsystem for Linux (WSL). WSL had two versions WSL1 and WSL2. Using WSL2 would have been much more convenient, but my version of windows wasn’t compatible with WSL2 as it required Version 1903 or higher, with Build 18362 or higher for x64 systems. With this obstacle, I had to stick to making WSL1 work but I still couldn’t get this to work, a series of issues came up which I was able to pass through with the help of my mentors until I got stuck at permission issues. I raised the issue with my mentor and after looking through the issue with me and trying to solve it to no avail, he suggested setting up an Ubuntu VM in Hyper-V. This article helped me achieve this and that solved my problem.

What did I learn?

I learned a lot more about the Jenkins project, Kubernetes, helm package manager, Jenkins Operator and much more. This project also gave me the opportunity to work with cloud providers like AWS which was totally new to me and also learn from field experts through knowledge sharing sessions and weekly meetings with my mentors and org admin. My technical writing skill and communication skill have definitely become better and I owe it to this project.

Overall, contributing to the Jenkins.io project is an amazing experience for me. I have been using Jenkins, and the fact that I was able to contribute to the organization and collaborate with the community is an honor.

3 Cases: Jenkins success stories from the community

$
0
0

Back in April, when we started canvassing the Jenkins community for user stories concerning how Jenkins helped enterprise companies, startups, and students, we thought we’d see some exciting tales of DevOps inspiration and CI/CD integration. We found that some submitted stories were far too big to be constrained by our format of 'background/goal/solution/results.'

Some Jenkins users had a much more complex story to tell, whether it was about getting upper management to buy-in, keeping developers happy, or simply making sure pipelines weren’t just bottlenecks in disguise.

Here are a handful of Jenkins Case Studies we’ve published in the past few months, with many more on the way!

Case Study #1: D4Science

Amping up scientific research with CI/CD powered by Jenkins

To promote open science practices and support scientific communities while serving 11k registered users in 45 countries, D4Science introduced a new delivery pipeline that replaced their pre-existing build platform.

Of course, they had to build and release their software framework (gCube) in a way that would support multi-project releases at scale — from 200+ Git repositories within the same day! It had to be fast, automate all release activities, and it had to deliver incremental releases to address user requirements quickly. Most of all, the solution had to be cost-effective.

Using Jenkins, they created an innovative approach to software delivery: a continuous integration/continuous delivery (CI/CD) pipeline, scalable, easy to maintain, and upgradable at a minimal cost.

Discover how D4Science empowers e-Science and virtual research communities with software released via Jenkins. Read the Jenkins case study featuring D4Science here!

Case Study #2: Gainsight

Humanizing CSX with tech innovation and a robust DevSecOps platform

Gainsight’s customer service experience platform helps customer success teams at more than 100 leading IT and healthcare clients. How? By driving engagement for tens of thousands of their customers.

That’s why the engineering team at Gainsight approached the customer experience by building a smarter, faster DevSecOps platform using Jenkins. They stuck to an infrastructure-as-code approach while integrating various tools and programming languages all within the platform. And they secured processes with better visibility and air-tight quality control.

The result was a flexible DevSecOps infrastructure, 95% of which is scalable with code. And the cost of infrastructure costs was 40% less. That provides Gainsight with ease of collaboration, keener operational insight, and — because builds are 30% faster — the ability to stay a step ahead of the competition.

Read why Gainsight’s lead DevOps engineer, Prudviraj Pentakota, says "Jenkins is the epicenter of DevSecOps in our organization." Get the full story here.

Case Study #3: Avoris Travel

Reinventing travel with an inventive technology platform

Part of Barceló Group, Ávoris Travel is behind prominent destination travel brands like LeSki, Le Musik, and a selection of author travels under its "Viagens Com Assinatura" signature travel concept. A proprietary database and a smart, dynamic booking engine are the tickets to offering differentiating and inventive travel opportunities.

Also unique to Avoris is a discreet machining technology that enables agents to enter specific criteria to search and find all types of trips and travel opportunities across the entire network.

"Our infrastructure is very important because we have to be online to meet customer demand anywhere in the world," said Alejandro Alvarez Vazquez, Sysadmin, Avoris Travel. "Our CI/CD platform is used by 200 people. The services that we build and deploy are used by thousands of potential clients and by our network of 675 own agencies located in Spain and Portugal."

Read the case study to learn how the flexibility of Jenkins plugins helped Avoris reduce build times by over 50% and became a go-to, scalable infrastructure supporting 675 agencies and over 2.8 million international consumers.

What’s your story?

We want to know what you’re building with Jenkins and would love to post your case study on our "Jenkins Is The Way" website, a global showcase of how developers and engineers build, deploy, and automate great stuff with Jenkins.

The best way to get started is to share your Jenkins User story with us. We’ll send you a free Jenkins Is The Way T-Shirt in return and publish your account for the entire Jenkins community to see. And if it’s selected for a Case Study, we’ll be in touch for a one-on-one interview! Hope to hear from you soon!

“Jenkins Contributors Awarded Top Honors at DevOps World 2020”

$
0
0

At DevOps World on September 24, 2020, through the sponsorship of CloudBees, three Jenkins contributors were recognized for their contributions to the Jenkins project. The Jenkins Contributor Awards honor those who have made significant contributions to the Jenkins project. The 2020 Jenkins Contributor Award winners are:

Most Valuable Jenkins Contributor

This award is presented to an individual who has contributed to the Jenkins project the most through new features, bug fixes or plugin development efforts.

  • Tim Jacomb - Tim is everywhere in the Jenkins community: plugins, Jenkins core maintenance, Google Summer of Code, infrastructure, and new initiatives like GitHub App authentication and Dark Theme. His software, frontend and infrastructure skills help to push the Jenkins project forward. Several examples of features shipped by Tim in 2020: Read-only Jenkins configuration, GitHub App Authentication support, Jenkins Dark Theme and many other smaller features here and there. Tim is also the second most active code reviewer in the Jenkins core.

Jenkins Security MVP

This award is presented to the individual who most consistently provides excellent Jenkins security reports or resolves Jenkins security issues.

  • James Holderness - Security issues reported by James have been included in nine of the nineteen security advisories published by the Jenkins project in the last 12 months. His issue reports have detected many cases where sensitive information was being stored insecurely by plugin maintainers. Jenkins users and the Jenkins security team are sincerely grateful for the issue reports that James has provided.

Most Valuable Jenkins Advocate

This award is presented to an individual who has helped advocate for Jenkins through organization of a local Jenkins Area Meetup(s), or virtual equivalent.

  • Marky Jackson - Marky has been very active in many Jenkins advocacy & Outreach initiatives. He was a leader of the Advocacy & Outreach SIG, and he participated in many promotional initiatives organized by the SIG. Marky was also a copy-editor of the Jenkins Twitter account where he contributed a lot to it. In addition to that, Marky has presented talks as well as provided technical support on Jenkins at multiple events including Jenkins Online Meetups, in person as well as virtual conferences.

Congratulations to James, Marky and Tim! We are grateful for their contributions to the betterment of the Jenkins project.

Google Summer of Code 2021 call for Project Ideas and Mentors

$
0
0
Google Summer of Code (GSoC) is a program where students are paid a stipend by Google to work on a free open source project. Students work on the project for three months (June to August). Prior to the coding phase, there is a month of community bonding, to welcome students to the Jenkins community and acquaint them with the projects processes for communication and collaboration. Mentors are actively involved with students from March when students start to work on and submit their applications. (see the timeline)

Jenkins GSoC

We are looking for project ideas and mentors to participate in GSoC 2021. GSoC project ideas are coding projects that university or college students can accomplish in about three months. 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 offer to mentor your project idea.

We accept new project ideas at any time, However, project ideas need to be finalised before February 19th, 2021 at 7pm UTC, which is the deadline for the Jenkins organization to apply to the GSoC program. 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

We currently have a list of project ideas for students to browse. Note that this list is subject to change.

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 students.

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 student proposals, pull-requests and the students presentations at the evaluation phase. They fill in the Google provided evaluation report form at the end of coding periods.

What do you get in exchange?

In return of mentoring, a student works on your project full time for three months. 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.

There will be a Google Mentor Summit which takes place every year. In 2020, the Mentor Summit was virtual, but in previous years the summit has taken place in person.

See this post about the 2019 in person Mentor Summit.

GSoC is a fantastic program and the Jenkins project is happy to participate in GSoC again in 2021!

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

Viewing all 1088 articles
Browse latest View live