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

Git Plugin Performance Improvement: Final Phase and Release

August 31, 2020, 6:14 am
$
0
0

Since the beginning of the project, the core value which drove its progress was "To enhance the user experience for running Jenkins jobs by reducing the overall execution time".

To achieve this goal, we laid out a path:

  • Compare the two existing git implementations i.e CliGitAPIImpl and JGitAPIImpl using performance benchmarking

  • Use the results to create a feature which would improve the overall performance of git plugin

  • Also, fix existing user reported performance issues

Let’s take a journey to understand how we’ve built the new features. If you’d like to skip the journey part, you can directly go to the [major performance improvements] section and the [minor performance section] to see what we’ve done!

Journey to release

The project started with deciding to choose a git operation and then trying to compare the performance of that operation by using command line git and then with JGit.

Stage 1: Benchmark results with git fetch

git-fetch-results

  • The performance of git fetch (average execution time/op) is strongly correlated to the size of a repository

  • There exists an inflection point on the scale of repository size after which the nature of JGit performance changes (it starts to degrade)

  • After running multiple benchmarks, it is safe to say that for a large sized repository command line git would be a better choice of implementation.

  • We can use this insight to implement a feature which avoids JGit with large repositories.

Stage 2: Comparing platforms

The project was also concerned that there might be important differences between operating systems. For example, what if command line Git for Windows performed very differently than command line Git on Linux or FreeBSD? Benchmarks were run to compare fetch performance on several platforms.

Running git fetch operation for a 400 MiB sized repository on:

  • AMD64 Microsoft Winders

  • AMD64 FreeBSD

  • IBM PowerPC 64 LE Ubuntu 18

  • IBM System 390 Ubuntu 18

The result of running this experiment is given below:

Performance on multiple platforms

The difference in performance between git and JGit remains constant across all platforms.

Benchmark results on one platform are applicable to all platforms.

Stage 3: Performance of git fetch and repository structure

git repo diagram

The area of the circle enclosing each parameter signifies the strength of the positive correlation between the performance of a git fetch operation and that parameter. From the diagram:

  • Size of the aggregated objects is the dominant player in determining the execution time for a git fetch

  • Number of branches and Number of tags play a similar role but are strongly overshadowed by size of repository

  • Number of commits has a negligible effect on the performance of running git fetch

After running these experiments from Stage-1 to Stage-3, we developed a solution called the GitToolChooser which is explained in the next stage

Stage 4: Faster checkout with Git tool chooser

This feature takes the responsibility of choosing the optimal implementation from the user and hands it to the plugin. It takes the decision of recommending an implementation on the basis of the size of the repository. Here is how it works.

git perf improv

The image above depicts the performance enhancements we have performed over the course of the GSoC project. These improvements have enabled the checkout step to be finished within half of what it used to take earlier in some cases.

Let’s talk about performance improvements in two parts.

Major performance improvements

Major performance enhancements

Building Tensorflow (~800 MiB) using a Jenkins pipeline, there is over 50% reduction in overall time spent in completing a job! The result is consistent multiple platforms.

The reason for such a decrease is the fact that JGit degrades in performance when we are talking about large sized repositories. Since the GitToolChooser is aware of this fact, it chooses to recommend command line git instead which saves the user some time.

Minor performance improvements

Note: Enable JGit before using the new performance features to let GitToolChooser work with more options→ Here’s how

git minor perf

Building the git plugin (~ 20 MiB) using a Jenkins pipeline, there is a drop of a second across all platforms when performance enhancement is enabled. Also, eliminating a redundant fetch reduces unnecessary load on git servers.

The reason for this change is the fact that JGit performs better than command line git for small sized repositories (<50MiB) as an already warmed up JVM favors the native Java implementation.

Releases

The road ahead

  • Support from other branch source plugins

    • Plugins like the GitHub Branch Source Plugin or GitLab Branch Source Plugin need to extend an extension point provided by the git plugin to facilitate the exchange of information related to size of a remote repository hosted by the particular git provider

  • JENKINS-63519: GitToolChooser predicts the wrong implementation

  • Addition of this feature to GitSCMSource

  • Detection of lock related delays accessing the cache directories present on the controller

    • This issue was reported by the plugin maintainer Mark Waite, there is a need to reproduce the issue first and then find a possible solution.

Reaching out

Feel free to reach out to us for any questions or feedback on the project’s Gitter Channel or theJenkins Developer Mailing list. Report an issue at Jenkins Jira.

Demonstration

↧
Search

GitHub Checks API Plugin Project - Coding Phase 3

September 1, 2020, 4:42 am
$
0
0

This blog post is about our phase 3 progress on GitHub Checks API Project, you can find our previous blog posts for phase 1 and phase 2.

At the end of this summer, the GSoC journey for GitHub Checks API Project comes to an end as well. In this blog post, I’ll show you our works during the last month:

  • Pipeline Support

  • Rerun Request Support

  • Git SCM Support

  • Documentation

All the above features will be available in our planned 1.0.0 version of Checks API Plugin and GitHub Checks Plugin.

Coding Phase 3 Demo

Pipeline Support

The pipeline support allows users to directly publish checks in their pipeline script without depending on any other consumers.

Pipeline Checks

The check in the above screenshot is published by script:

publishChecks name: 'pipeline check', title: 'pipeline ', summary: '# A pipeline check example',text: "## This check is published through the pipeline script",detailsURL: 'https://ci.jenkins.io'

If you want to publish checks to GitHub, please install the GitHub implementation and refer to the GitHub API documentation for the requirements for each field. A default value (build link) for detailsURL will be provided automatically.

This feature can be useful when many stages exist in your pipeline script and each takes a long time: you can publish a check for each stage to keep track of the build.

Rerun Request Support

The rerun request allows GitHub users to rerun the failed builds. When a build failed (which leads to a failed check), a Re-run button will be added automatically by GitHub.

Failed Checks

By clicking the Re-run button, Jenkins will reschedule a build for the last commit of this branch.

Since all checks of a commit are produced by a single build, you don’t have to rerun all failed checks, just rerun any one of the failed check will refresh all checks.

Git SCM Support

Thanks to Ullrich's great help, the GitHub Checks Plugin now supports Git SCM. This means now you can publish checks for your freestyle project or any other projects that use Git SCM.

Document

Consumers Guide and Implementation Guide are now available. As a Jenkins developer, you can now start consuming our API or even providing an implementation for other SCM platforms beside GitHub.

Acknowledgment

The whole GitHub Checks API project is started as a Google Summer of Code project. Much appreciate my mentors (Tim and Ullrich) for their great help during the whole summer. Also huge thanks to the Jenkins GSoC SIG and the whole community for the technique support and resources.

Resources

↧
↧

Custom Distribution Service : Phase 3 Blogpost

September 1, 2020, 4:42 am
$
0
0

Hello everyone,

This is the final blog post for the Custom Distribution Service project during the Google Summer of Code timeline. I have mixed feelings since we are almost near the finish line for one of the most amazing open source programs out there. However, it is time to wrap things up for this project and achieve a state where the project can be built upon and extended further. This phase has been super busy with respect to the bug fixes, testing and getting the project hosted, so let us get straight into the phase 3 updates.

Fixes and Code quality assurance

Set Jenkinsfile agent to linux

We realised that the build was failing on windows and that there was not really a use-case for running it on windows for right now. Maybe it could be on a future roadmap. Therefore, we decided to shift the testing to only linux agents with respect to running the tests on the jenkins server.

Backend port error message

Spring boot has a default message on the port:8080 and therefore we wanted to change it to a custom message on the backend. So the major takeaway here is that we needed to implement the Error Controller interface and include a custom message in it. This was technical debt from the last phase and was completed and merged during this phase.

  • Pull Request #92

PMD Analysis

In order to enhance the quality of the code, the PMD source code analyser was applied to the project. It helped me catch tons of errors. When the initial PMD check was run and we found approximately 162 PMD errors. We realised some of them were not relevant and some of them could be fixed later.

Findbugs Analysis

Another tool to improve code quality that we included in this phase was findbugs. It did catch around 5-10 bugs in my code which I immediately resolved. Most of them were around the Closeable HTTP Request and an easy fix was the try with resources.

Jacoco Code Coverage

We needed to make sure most of the code we write had proper coverage for all branches and lines. Therefore we decided to include a JaCoco Code Coverage reporter that helped us find the uncovered lines and areas we need to improve coverage on.

Remove JCasC generation

While developing the service we quickly realised that the generation of the war package broke if we included a configuration as code section but did not provide a path to the corresponding required yml file. Therefore we took a decision to remove the casc section all together. Maybe it will comeback in a future patch

  • Pull Request link: #127

  • Issue link: #65

Minor Fixes

  • Logging Fix: #99

  • Docs Fix : link: #120

  • Update Center Dump Fix : link: #125

  • Class Path Fix: link: #126

  • Release Drafter Addition: link: #136

Front end

There was no community configuration link present for navigation which was added here. Now it is easier to navigate to the community page from the home page itself.

Docker updates

Build everything with Docker

This was one of the major changes this phase with respect to making the service very easy to spin up locally, this change will greatly help community adoption since it eliminates the tools one needs to install locally. Initially the process was to run maven locally, generate all of the files and then copy all of its contents into the container. However, with this change we are going to generate all of the files inside the docker container itself. Allowing the user to just run a couple of commands to get the service up and running.

So some of the major changes we did with respect to the dockerfile was:

a) Copy all of the configuration files and pom.xml into the container.

b) Run the command mvn clean package inside the container which generates the jar.

c) Run the jar inside the container.

Hosting updates

This process was supposed to be a future roadmap, however the infra team approved and was super helpful in making this process as smooth as possible. Thanks to Gavin, Tim and Oblak for making this possible. Here is the google group dicussion

The project has now been hosted here as a preview. It still needs some fixes to be fully functional.

  • Infra Docker PR #131

  • Infra Project Addition PR link: #393

Testing Updates

Unit test the services

With respect to community hosting and adoption, testing of the service one of the most important and major milestones for this phase was to test the majority of the code and we have completed the testing with flying colors. All of the services have been completely unit tested, which is a major accomplishment. For the testing of the service we decided to go with wiremock which can be used to mock external services. Kezhi’s comment helped us to understand what we needed to do since he had done something quite similar in his Github Checks API project.

So we basically wiremocked the update-center url and made sure we were getting the accurate response with appropriate control flow logic tested.

wireMockRule.stubFor(get(urlPathMatching("/getUpdateCenter"))
                .willReturn(aResponse()
                        .withStatus(200)
                        .withHeader("Content-Type", "application/json")
                        .withBody(updateCenterBody)));

Add Update Center controller tests

Another major testing change involved testing the controllers. For this we decided to use the wiremock library in java to mock the server response when the controllers were invoked.

For example: If I have a controller that serves in an api called /api/plugin/getPluginList wiremock can be used to stub out its response when the system is under test. So we use something like this to test it out.

 when(updateService.downloadUpdateCenterJSON()).thenReturn(util.convertPayloadToJSON(dummyUpdateBody))

When the particular controller is called the underlying service is mocked and it returns a response according to the one provided by us. To find more details the PR is here.

Add Packager Controller Tests

Along with the update center controller tests another controller that needed to be tested was the packager controller. Also we needed to make sure that all the branches for the controllers were properly tested. Additional details can be found in the PR below.

Docker Compose Tests

One problem that we faced the entire phase was the docker containers. We regularly found out that due to some changes in the codebase the docker container build sometimes broke, or even sometimes the inner api’s seemed to malfunction. In order to counteract that we decided to come up with some tests locally. So what I did was basically introduce a set of bash scripts that would do the following:

a) Build the container using the docker-compose command.

b) Run the container.

c) Test the api’s using the exposed port.

d) Teardown the running containers.

User Documentation

We also included a user docs guide so that it makes it super easy to get started with the service.

Future Roadmap

This has been a super exciting project to work on and I can definitely see this project being built upon and extended in the future.

I would like to talk about some of the features that are left to come in and can be taken up in a future roadmap discussion

a) JCasC Support:

Description: Support the generation of a Jenkins Configuration as Code file asking the user interactively for the plugins they select what would be the configuration they would want eg: If the user selects the slack plugin we need to ask him questions like what is the slack channel? what is the token? etc, and on the basis of this generate a casc file. This feature was initially planned to go into the service but we realised this is a project in its own capacity.

b) Auto Pull Request Creation:

Description: Allow users to create a configuration file and immediately open a pull request on github without leaving the user interface. This was originally planned using a github bot and we started the work on it. But we were in doubt if the service would be hosted or not and therefore put the development on hold. You can find the pull requests here:

  • Github Controller #72

  • Pull Request Creation Functions #66

c) Synergy with Image Controller

Description: This feature requires some planning, some of the questions we can ask are:

a) Can we generate the images (i.e Image Controller). b) Can we have the service as a multipurpose generator ?

Statistics

This phase has been the busiest of all phases and it has involved a lot of work, more than I had initially expected in the phase. Although lines of code added is not an indication of work done, however 800 lines of Code added is a real personal milestone for me.

Gitter Channel Link
GSoC Proposal
Design Document
Daily Notes

Pull Requests Opened

26

Lines of Code Added

1096

Lines of Docs Added

200

↧

Learn more about Jenkins' continuous evolution at CDCon

September 10, 2020, 9:12 pm
$
0
0

The Jenkins project has been around for over fifteen years and is the defacto platform for CI/CD. One of the reasons it continues to be so ubiquitous is that Jenkins constantly evolves and offers flexibility to integrate other tools that work well for your solution.

At CDCon, on October 7-8, there are two particular Jenkins talks that will focus on new directions that the Jenkins platform is evolving too and getting better and better for users.

Heard of JCasC and Not Sure Where to Start? Let me Help You!

Configuration as code is a best practice for your CI/CD setup as it makes the complex process of setting up Jenkins simpler and more reproducible. Jenkins Configuration as Code (JCasc) enables Jenkins users to define the whole configuration as a simple, plain text YAML syntax. With JCasc, setting up a new Jenkins master is easier than ever before. To get started with JCasC some initial effort is required. This talk walks you through a basic setup for easily spinning up new Jenkins instances.

October 7 at 2:20 PM PST Speaker: Ewelina Wilkosz, Eficode

Ewelina W is passionate about making sure that her customers' software is being built, tested and released in the best possible way. And, most importantly, that software developers don’t hate the process. Ewelina has been involved in Jenkins Configuration as Code plugin development from the very beginning. This is a must-see talk where Ewelina will also share some tips and tricks. The talk will feature using Docker, Jenkins and GitHub Actions as a quick way to build… Jenkins!

Bridging the Gap with Tekton-client-plugin for Jenkins

Tekton provides Kubernetes-native CI/CD building blocks. It enables users to take full advantage of cloud-native features around scalability and high availability. Jenkins flexibility enables integration with Tekton. This talk showcases the new tekton-client-plugin for Jenkins that enables Jenkins to interact with Tekton pipelines on a Kubernetes cluster. Tekton and Jenkins are both CDF projects and this talk highlights the first steps towards better Tekton and Jenkins interoperability, a key goal of the CD Foundation.

October 7 at 11:40 AM PST Speaker: Vibhav Bobade, Red Hat

Register for CDCon

Both these talks showcase the ultimate flexibility and power of the Jenkins platform and how it continues to evolve to meet the challenges of modern-day CI/CD. Don’t miss out; register for CDCon to attend.

CDCon has pledged to donate 100% of the proceeds received from CDCon 2020 registration to charitable causes: Black Girls Code, Women Who Code and the CDF Diversity Fund. Registrants indicate which charitable fund they want their 25 USD registration fees to go to during registration. If you can’t afford the registration cost, please apply for the diversity scholarship.

Register for CDCon
↧

Testing Jenkins 2.249.1 on Windows

September 11, 2020, 9:12 am
$
0
0

This article describes our observations during Windows testing of the Jenkins 2.249.1 release candidate.

Upgrade testing

Jenkins 2.249.1 is a new long term support release with user interface improvements and changes in Windows support. It is the first long term support release to drop support for Microsoft.NET framework 2.0. The end of support for Microsoft.NET framework 2.0 was announced in the Windows Support Updates blog post. The Windows support upgrade guidelines describe major things to consider when upgrading Jenkins controllers and agents on Windows.

As part of our preparation for the release, we tested several configurations. This article describes our experiences with those configurations.

Upgrade approaches

We tested controller and agent upgrades from Jenkins 2.235.x to 2.249.1-rc on Windows. The tests included:

Upgrade process

Our upgrade process included:

  • Install a previous version of Jenkins controller on Windows

  • Install a previous version of Jenkins agent on Windows and configure it as a service

  • Upgrade Jenkins controller from "Manage Jenkins"

  • Restart the Jenkins Windows service for the controller

  • Upgrade the Jenkins agent on Windows with the latest agent.jar

  • Restart the Jenkins Windows service for the agent

Testing results

We successfully tested

We confirmed that we can continue our Level 1 support policy for Jenkins 2.249.1.

32 bit Windows MSI

Prior to Jenkins 2.235.3, the Jenkins LTS Windows installer was provided as a 32 bit MSI and included a bundled Java 8 runtime environment. The Jenkins agent can be downloaded and run through Java web start using the bundled Java 8 runtime environment. The agent can also be configured to run as a service using the bundled Java 8 runtime environment.

Jenkins controller

Jenkins 2.235.1 installs JRE 8u144 for 32 bit Windows. The installer configures the Jenkins controller to run as the SYSTEM user.

Refer to the Windows Installer Updates blog post for details of the controller installation process with the 32 bit MSI.

Jenkins agent

Jenkins agents on Windows are often configured to "Launch agent by connecting it to the master". The Jenkins agent configuration correctly warns that the controller must open the TCP port for inbound agents in the "Configure Global Security" page. It is easiest to allow Jenkins to choose the port (a "Random" port). Jenkins selects a random available port number and shares that port number with agents during their initial connection to the Jenkins http port.

TCP port for inbound agents

Configure the agent

Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller.

Inbound agent configuration

Download the agent

The agent starts the first time by clicking the "Launch" button on the agent configuration page (only available with Java 8). That downloads the "slave-agent.jnlp" file from the web browser.

Launch inbound agent from Jenkins

Start the agent

The downloaded file needs to be opened from a command prompt using the javaws command that is included with the bundled JRE:

C:\> "C:\Program Files (x86)\Jenkins\jre\bin\javaws.exe" -wait slave-agent.jnlp
The javaws program has been removed from the most recent releases of Java 8 and from Java 11. Refer to [Jenkins agent and icedtea] for a technique that can help users of the most recent releases of Java 8.

Java web start (javaws.exe) prompts for permission to run the program with this dialog:

Java Web Start prompt for remoting agent

Install the agent as a service

The agent runs and displays a window on the desktop with a single menu entry, "Install as a service".

Install agent as a service

When the "Install as a service" menu item is clicked, the agent is adjusted to run as a Windows service using the SYSTEM account.

Upgrade the controller

The Jenkins controller on Windows can be upgraded to Jenkins 2.249.1 from the "Manage Jenkins" page. The upgrade process downloads the new jenkins.war file, saves the current version in case of later downgrade, and offers to restart.

Upgrade Jenkins from Manage Jenkins

Upgrade the agent

The Jenkins inbound agent is not upgraded automatically. The agent administrator downloads the most recent agent.jar from their Jenkins controller, stops the running agent, and replaces the installed agent.jar with the downloaded version. The agent service will reconnect to the Jenkins controller after the administrator restarts it.

64 bit Windows MSI

Beginning with Jenkins 2.235.3, the Jenkins LTS Windows installer is a 64 bit MSI. It runs Jenkins with the 64 bit JDK (Java 8 or Java 11) selected by the user.

Jenkins controller

Jenkins 2.235.3 was installed using AdoptOpenJDK Java 8u262 in one test. It was installed using AdoptOpenJDK Java 11.0.8 in another test. In both cases, the installer configured the Jenkins controller to run with the Windows service account we had previously configured.

Refer to the Windows Installer Updates blog post for details of the controller installation process with the 64 bit MSI.

Jenkins agent

Jenkins agents on Windows are often configured to "Launch agent by connecting it to the master". The Jenkins agent configuration correctly warns that the controller must open the TCP port for inbound agents in the "Configure Global Security" page. It is easiest to allow Jenkins to choose the port (a "Random" port). Jenkins selects a random available port number and shares that port number with agents during their initial connection to the Jenkins http port.

TCP port for inbound agents

Configure the agent

Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller. Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller. Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller.

Inbound agent configuration

Download the agent

The agent was started the first time by clicking the "Launch" button on the agent configuration page (only available with Java 8). That downloads the "slave-agent.jnlp" file from the web browser.

Launch inbound agent from Jenkins

Start the agent with IcedTea-Web

Recent versions of Java 8 and all versions of Java 11 have removed the javaws command. Jenkins agents for Java 8 can still be started with the javaws command, but it needs to be downloaded separately from the JVM. We open "slave-agent.jnlp" from a command prompt using the javaws command that is available from AdoptOpenJDK IcedTea:

C:\> C:\icedtea-web-1.8.3.win.bin\icedtea-web-image\bin\javaws.exe -wait slave-agent.jnlp

Java web start (javaws.exe) prompts for permission to run the program with this dialog:

Java Web Start prompt for remoting agent

Install the agent as a service

The agent runs and displays a window on the desktop with a single menu entry, "Install as a service".

Install agent as a service

When the "Install as a service" menu item is clicked, the agent is installed and configured to run as a Windows service using the SYSTEM account.

Upgrading the controller

The Jenkins controller on Windows was upgraded to Jenkins 2.249.1 from the "Manage Jenkins" page. The upgrade process downloads the new jenkins.war file, saves the current version in case of later downgrade, and offers to restart.

Upgrade Jenkins from Manage Jenkins

Upgrading the agent

The Jenkins inbound agent is not upgraded automatically or from a Jenkins user interface. The agent administrator downloads the most recent agent.jar from their Jenkins controller and replaces the installed agent.jar with the downloaded version.

WAR (file) on Windows

Jenkins allows users to run the Jenkins web archive (WAR) file from a command line and then install it as a service from within Jenkins. This installation technique uses the Jenkins WAR file but does not use a Windows MSI package. The Jenkins WAR file includes the necessary components to install and configure Jenkins as a service.

Install controller as a service

When the Jenkins war file is started from a Windows command prompt, "Manage Jenkins" includes "Install as a service". An administrator selects that entry and Jenkins will configure itself to run as a service/ The installer configures the Jenkins controller to run as the SYSTEM user.

Install Jenkins as a service from Manage Jenkins

Jenkins agent

Jenkins agents on Windows are often configured to "Launch agent by connecting it to the master". The Jenkins agent configuration correctly warns that the controller must open the TCP port for inbound agents in the "Configure Global Security" page. It is easiest to allow Jenkins to choose the port (a "Random" port). Jenkins selects a random available port number and shares that port number with agents during their initial connection to the Jenkins http port.

TCP port for inbound agents

Configure the agent

After opening the Jenkins TCP port for inbound agents, we configured a new agent from the "Nodes" menu This created an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller.

Inbound agent configuration

Download the agent

The agent was started the first time by clicking the "Launch" button on the agent configuration page (only available with Java 8). That downloads the "slave-agent.jnlp" file from the web browser.

Launch inbound agent from Jenkins

Start the agent with IcedTea-Web

Recent versions of Java 8 and all versions of Java 11 have removed the javaws command. Jenkins agents for Java 8 can still be started with the javaws command, but it needs to be downloaded separately from the JVM. Open "slave-agent.jnlp" from a command prompt using the javaws command that is available from AdoptOpenJDK IcedTea-Web:

C:\> C:\icedtea-web-1.8.3.win.bin\icedtea-web-image\bin\javaws.exe -wait slave-agent.jnlp

Java web start (javaws.exe) prompts for permission to run the program with this dialog:

Java Web Start prompt for remoting agent

Install the agent as a service

The agent runs and displays a window on the desktop with a single menu entry, "Install as a service".

Install agent as a service

When the "Install as a service" menu item is clicked, the agent is installed and configured to run as a Windows service using the SYSTEM account.

Conclusion

Jenkins controller installation is best done with the new 64 bit MSI package. Previous controller installations can be upgraded to the most recent Jenkins release from within Jenkins.

Jenkins inbound agent installation is more complicated now that the javaws.exe program is not included in the JDK. The AdoptOpenJDK IcedTea-Web project allows administrators to install and configure Jenkins inbound agents with most of the ease that was available in prior Java releases.

↧
↧

Jenkins at DevOps World 2020

September 20, 2020, 12:12 am
$
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)

Speaker: Steven Terrana

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!

September 25, 2020, 5:42 am
$
0
0

We are happy to announce the 2020 elections in the Jenkins project! Nominations are open for one 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.

Key dates

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

  • Oct 15 - Board and officer nominations deadline.

  • Oct 22 - List of candidates is published, including personal statements.

  • Nov 02 - Voting sign-up is over.

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

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

Deadline for the voter registration is November 02.

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.

References

↧

Documenting Jenkins on Kubernetes Introduction

September 25, 2020, 3:03 pm
$
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

↧
Search

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

October 21, 2020, 1:17 pm
$
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

October 21, 2020, 9:42 pm
$
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']],doGenerateSubmoduleConfigurations: false,extensions: [
          [$class: 'SparseCheckoutPaths',sparseCheckoutPaths:
            [[$class:'SparseCheckoutPath', path:'package.json,pom.xml']]
          ]
      ],submoduleCfg: [],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

October 28, 2020, 2:43 pm
$
0
0

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!

Key dates

  • Nov 08 - Voting sign-up is over.

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

  • 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 pains 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.

Profile links:GitHub,Twitter,LinkedIn,Jenkins Blog

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.

Profile links:GitHub,Twitter,LinkedIn,Jenkins Blog

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

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:Twitter,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.

Profile links:Twitter,Jenkins Blog

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:Twitter,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:Twitter,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.

Profile links:GitHub,Twitter,LinkedIn,Jenkins Blog

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.

Profile links:GitHub,Twitter,Jenkins Blog

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.

Profile links:GitHub,Twitter,LinkedIn,Jenkins Blog

Affiliations: CloudBees

More information

↧

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

November 4, 2020, 1:42 pm
$
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

November 5, 2020, 2:12 pm
$
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.

Additional Resources

↧
↧

Spring and XStream updates (breaking changes!)

November 13, 2020, 3:12 pm
$
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

November 13, 2020, 3:12 pm
$
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.

↧
Search

2020 Jenkins Board and Officer Elections Results

December 3, 2020, 6:12 pm
$
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 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.

References

↧

GSOD Project Report: Document Jenkins on Kubernetes

December 4, 2020, 6:13 pm
$
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:

Katakoda 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

December 7, 2020, 10:14 am
$
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”

December 13, 2020, 7:43 am
$
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

December 18, 2020, 2:13 pm
$
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
Search