Authenticating as a GitHub app brings many benefits:
Larger rate limits – The rate limit for a GitHub app scales with your organization size, whereas a user based token has a limit of 5000 regardless of how many repositories you have.
User-independent authentication – Each GitHub app has its own user-independent authentication. No more need for ‘bot’ users or figuring out who should be the owner of 2FA or OAuth tokens.
Improved security and tighter permissions – GitHub Apps offer much finer-grained permissions compared to a service user and its personal access tokens. This lets the Jenkins GitHub app require a much smaller set of privileges to run properly.
Access to GitHub Checks API – GitHub Apps can access the the GitHub Checks API to create check runs and check suites from Jenkins jobs and provide detailed feedback on commits as well as code annotation
Getting started
Install the GitHub Branch Source plugin, make sure the version is at least 2.7.0-beta1. Installation guidelines for beta releases are available here
Once you’ve finished setting it up, Jenkins will validate your credential and you should see your new rate limit. Here’s an example on a large org:
How do I get an API token in my pipeline?
In addition to usage of GitHub App authentication for Multi-Branch Pipeline, you can also use app authentication directly in your Pipelines. You can access the Bearer token for the GitHub API by just loading a ‘Username/Password’ credential as usual, the plugin will handle authenticating with GitHub in the background.
This could be used to call additional GitHub API endpoints from your pipeline, possibly the deployments api or you may wish to implement your own checks api integration until Jenkins supports this out of the box.
Note: the API token you get will only be valid for one hour, don’t get it at the start of the pipeline and assume it will be valid all the way through
Example: Let’s submit a check run to Jenkins from our Pipeline:
pipeline {
agent any
stages{
stage('Check run') {
steps {
withCredentials([usernamePassword(credentialsId: 'githubapp-jenkins',
usernameVariable: 'GITHUB_APP',
passwordVariable: 'GITHUB_JWT_TOKEN')]) {
sh '''
curl -H "Content-Type: application/json" \
-H "Accept: application/vnd.github.antiope-preview+json" \
-H "authorization: Bearer ${GITHUB_JWT_TOKEN}" \
-d '{ "name": "check_run", \
"head_sha": "'${GIT_COMMIT}'", \
"status": "in_progress", \
"external_id": "42", \
"started_at": "2020-03-05T11:14:52Z", \
"output": { "title": "Check run from Jenkins!", \
"summary": "This is a check run which has been generated from Jenkins as GitHub App", \
"text": "...and that is awesome"}}' https://api.github.com/repos/<org>/<repo>/check-runs
'''
}
}
}
}
}
What’s next
GitHub Apps authentication in Jenkins is a huge improvement. Many teams have already started using it and have helped improve it by giving pre-release feedback. There are more improvements on the way.
There’s a proposed Google Summer of Code project: GitHub Checks API for Jenkins Plugins. It will look at integrating with the Checks API, with a focus on reporting issues found using the warnings-ng plugin directly onto the GitHub pull requests, along with test results summary on GitHub. Hopefully it will make the Pipeline example below much simpler for Jenkins users 🙂 If you want to get involved with this, join the GSoC Gitter channel and ask how you can help.
Problem Statement: Convert the existing schema validation workflow from the current scripting language in the Jenkins Configuration as Code Plugin to a Java based rewrite thereby enhancing its readablity and testability supported by a testing framework for the same. Enhance developer experience by developing a VSCode Plugin to facilitate autocompletion and validation which would help the developer write correct yaml files before application to a Jenkins Instance.
The Configuration as Code plugin has been designed as an opinionated way to configure Jenkins based on human-readable declarative configuration files. Writing such a file should be feasible without being a Jenkins expert, just translating into code a configuration process one is used to executing in the web UI. The plugin uses a schema to verify the files being applied to the Jenkins instance.
With the new JSON Schema being enabled developers can now test their yaml file against it. The schema checks the descriptors i.e. configuration that can be applied to a plugin or Jenkins core, the correct type is used and help text is provided in some cases. VSCode allows us to test out the schema right out of the box with some modifications. This project was built as part of the Community Bridge initiative which is a platform created by the Linux Foundation to empower developers — and the individuals and companies who support them — to advance sustainability, security, and diversity in open source technology. You can take a look at the Jenkins Community Bridge Project Page
Steps to Enable the Schema Validation
a) The first step includes installing the JCasC Plugin for Visual Studio Code and opening up the extension via the extension list. Shortcut for opening the extension list in VSCode editor using Ctrl + Shift + X.
b) In order to enable validation we need to include it in the workspace settings. Navigate to File and then Preference and then Settings. Inside settings search for json and inside settings.json include the following configuration.
{
"yaml.schemas": {
"schema.json": "y[a]?ml"
}
}
You can specify a glob pattern as the value for schema.json which is the file name for the schema. This would apply the schema to all yaml files. eg: .[y[a]?ml]
c) The following tasks can be done using VSCode:
a) Auto completion (Ctrl + Space):
Auto completes on all commands.
b) Document Outlining (Ctrl + Shift + O):
Provides the document outlining of all completed nodes in the file.
d) Create a new file under the work directory called jenkins.yml. For example consider the following contents for the file:
The above yaml file is valid according to the schema and vscode should provide you with validation and autocompletion for the same.
Screenshots
We are holding an online meetup on the 26th February regarding this plugin and how you could use it to validate your YAML configuration files. For any suggestions or dicussions regarding the schema feel free to join our gitter channel. Issues can be created on Github.
I am happy to report that JEP-222 has landed in Jenkins weeklies, starting in 2.217. This improvement brings experimental WebSocket support to Jenkins, available when connecting inbound agents or when running the CLI. The WebSocket protocol allows bidirectional, streaming communication over an HTTP(S) port.
While many users of Jenkins could benefit, implementing this system was particularly important for CloudBees because of how CloudBees Core on modern cloud platforms (i.e., running on Kubernetes) configures networking. When an administrator wishes to connect an inbound (formerly known as “JNLP”) external agent to a Jenkins master, such as a Windows virtual machine running outside the cluster and using the agent service wrapper, until now the only option was to use a special TCP port. This port needed to be opened to external traffic using low-level network configuration. For example, users of the nginx ingress controller would need to proxy a separate external port for each Jenkins service in the cluster. The instructions to do this are complex and hard to troubleshoot.
Using WebSocket, inbound agents can now be connected much more simply when a reverse proxy is present: if the HTTP(S) port is already serving traffic, most proxies will allow WebSocket connections with no additional configuration. The WebSocket mode can be enabled in agent configuration, and support for pod-based agents in the Kubernetes plugin is coming soon. You will need an agent version 4.0 or later, which is bundled with Jenkins in the usual way (Docker images with this version are coming soon).
Another part of Jenkins that was troublesome for reverse proxy users was the CLI. Besides the SSH protocol on port 22, which again was a hassle to open from the outside, the CLI already had the ability to use HTTP(S) transport. Unfortunately the trick used to implement that confused some proxies and was not very portable. Jenkins 2.217 offers a new -webSocket CLI mode which should avoid these issues; again you will need to download a new version of jenkins-cli.jar to use this mode.
The WebSocket code has been tested against a sample of Kubernetes implementations (including OpenShift), but it is likely that some bugs and limitations remain, and scalability of agents under heavy build loads has not yet been tested. Treat this feature as beta quality for now and let us know how it works!
We know that for many of our customers Jenkins is incredibly important and its integration with Bitbucket Server is a key part of their development workflow. Unfortunately, we also know that integrating Bitbucket Server with Jenkins wasn’t always easy – it may have required multiple plugins and considerable time. That’s why earlier this year we set out to change this. We began building our own integration, and we’re proud to announce that v1.0 is out.
The new Bitbucket Server integration for Jenkins plugin, which is built and supported by Atlassian, is the easiest way to link Jenkins with Bitbucket Server. It streamlines the entire set-up process, from creating a webhook to trigger builds in Jenkins, to posting build statuses back to Bitbucket Server. It also supports smart mirroring and lets Jenkins clone from mirrors to free up valuable resources on your primary server.
Our plugin is available to install through Jenkins now. Watch this video to find out how, or read the BitBucket Server solution page to learn more about it.
Once you’ve tried it out we’d love to hear any feedback you have. To share it with us, visit https://issues.jenkins-ci.org and create an issue using the component atlassian-bitbucket-server-integration-plugin.
Hello friends! I am Marky Jackson and I am so thrilled to be one of the newest CDF ambassadors.
I have been involved in open source for many years but my start in the world was rather rocky. I had a difficult childhood. I was shuffled from one boys’ home to another and had little control over my life. But I was tough and smart, and I emancipated at an early age, which allowed me to start living the way I wanted while I was still in my teens.
I studied computer science at UCLA and MIT and then spent 14 months as an intern at Jasmine Multimedia Publishing before joining companies such as Yahoo, AT&T, HP, Symantec and more.
I am extremely excited to be a part of this program because I get to make people smile by mentoring and being positive. I love public speaking, doing a meetup in person or virtual and helping people online. I get joy when a person gets involved in the open-source community.
The open source community is all about inclusion. We welcome people to contribute, and we try to express our gratitude for their hard work. The sense of unity and belonging is second to none with developers, coders, and engineers from around the world collaborating to advance our industry.
It takes a lot of time and effort to keep the open-source community going. Most of us are working after-hours to get things done, and we need help—lots of help. People think that you have to be an expert coder to join us, but that’s not true. There are plenty of ways to take part in. You can contribute error reports, write technical documentation, or even sponsor an application. There are plenty of ways to offer support. Just ask what you can do.
I look forward to meeting everyone and collaborating! You can find me at @markyjackson5 on Twitter.
From Dailymotion, a French video-sharing technology platform with over 300 million unique monthly users
At Dailymotion, we are hosting and delivering premium video content to users all around the world. We are building a large variety of software to power this service, from our player or website to our GraphQL API or ad-tech platform. Continuous Delivery is a central practice in our organization, allowing us to push new features quickly and in an iterative way.
We are early adopters of Kubernetes: we built our own hybrid platform, hosted both on-premise and on the cloud. And we heavily rely on Jenkins to power our “release platform”, which is responsible for building, testing, packaging and deploying all our software. Because we have hundreds of repositories, we are using Jenkins Shared Libraries to keep our pipeline files as small as possible. It is an important feature for us, ensuring both a low maintenance cost and a homogeneous experience for all developers – even though they are working on projects using different technology stacks. We even built Gazr, a convention for writing Makefiles with standard targets, which is the foundation for our Jenkins Pipelines.
In 2018, we migrated our ad-tech product to Kubernetes and took the opportunity to set up a Jenkins instance in our new cluster – or better yet move to a “cloud-native” alternative. Jenkins X was released just a few months before, and it seemed like a perfect match for us:
It is built on top and for Kubernetes.
At that time – in 2018 – it was using Jenkins to run the pipelines, which was good news given our experience with Jenkins.
It comes with features such as preview environments which are a real benefit for us.
And it uses the Gitops practice, which we found very interesting because we love version control, peer review, and automation.
While adopting Jenkins X we discovered that it is first a set of good practices derived from the best performing teams, and then a set of tools to implement these practices. If you try to adopt the tools without understanding the practices, you risk fighting against the tool because it won’t fit your practices. So you should start with the practices. Jenkins X is built on top of the practices described in the Accelerate book, such as micro-services and loosely-coupled architecture, trunk-based development, feature flags, backward compatibility, continuous integration, frequent and automated releases, continuous delivery, Gitops, … Understanding these practices and their benefits is the first step. After that, you will see the limitations of your current workflow and tools. This is when you can introduce Jenkins X, its workflow and set of tools.
We’ve been using Jenkins X since the beginning of 2019 to handle all the build and delivery of our ad-tech platform, with great benefits. The main one being the improved velocity: we used to release and deploy every two weeks, at the end of each sprint. Following the adoption of Jenkins X and its set of practices, we’re now releasing between 10 and 15 times per day and deploying to production between 5 and 10 times per day. According to the State of DevOps Report for 2019, our ad-tech team jumped from the medium performers’ group to somewhere between the high and elite performers’ groups.
But these benefits did not come for free. Adopting Jenkins X early meant that we had to customize it to bypass its initial limitations, such as the ability to deploy to multiple clusters. We’ve detailed our work in a recent blog post, and we received the “Most Innovative Jenkins X Implementation” Jenkins Community Award in 2019 for it. It’s important to note that most of the issues we found have been fixed or are being fixed. The Jenkins X team has been listening to the community feedback and is really focused on improving their product. The new Jenkins X Labs is a good example.
As our usage of Jenkins X grows, we’re hitting more and more the limits of the single Jenkins instance deployed as part of Jenkins X. In a platform where every component has been developed with a cloud-native mindset, Jenkins is the only one that has been forced into an environment for which it was not built. It is still a single point of failure, with a much higher maintenance cost than the other components – mainly due to the various plugins.
In 2019, the Jenkins X team started to replace Jenkins with a combination of Prow and Tekton. Prow (or Lighthouse) is the component which handles the incoming webhook events from GitHub, and what Jenkins X calls the “ChatOps”: all the interactions between GitHub and the CI/CD platform. Tekton is a pipeline execution engine. It is a cloud-native project built on top of Kubernetes, fully leveraging the API and capabilities of this platform. No single point of failure, no plugins compatibility nightmare – yet.
Since the beginning of 2020, we’ve started an internal project to upgrade our Jenkins X setup – by introducing Prow and Tekton. We saw immediate benefits:
Faster scheduling of pipelines “runners” pods – because all components are now Kubernetes-native components.
Simpler pipelines – thanks to both the Jenkins X Pipelines YAML syntax and the ability to easily decouple a complex pipeline in multiple small ones that are run concurrently.
Lower maintenance cost.
While replacing the pipeline engine of Jenkins X might seem like an implementation detail, in fact, it has a big impact on the developers. Everybody is used to see the Jenkins UI as the CI/CD UI – the main entry point, the way to manually restart pipelines executions, to access logs and test results. Sure, there is a new UI and a real API with an awesome CLI, but the new UI is not finished yet, and some people still prefer to use web browsers and terminals. Leaving the Jenkins Plugins ecosystem is also a difficult decision because some projects heavily rely on a few plugins. And finally, with the introduction of Prow (Lighthouse) the Github workflow is a bit different, with Pull Requests merges being done automatically, instead of people manually merging when all the reviews and automated checks are green.
So if 2019 was the year of Jenkins X at Dailymotion, 2020 will definitely be the year of Tekton: our main release platform – used by almost all our projects except the ad-tech ones – is still powered by Jenkins, and we feel more and more its limitations in a Kubernetes world. This is why we plan to replace all our Jenkins instances with Tekton, which was truly built for Kubernetes and will enable us to scale our Continuous Delivery practices.
If you are interested to know more about Jenkins features introduced in 2019, stay tuned for a separate blog post about it (coming soon!).
Project updates
Highlights above do not cover all advancements we had in the project. Below you can find slides from the Jenkins contributor summit in Lisbon. There we had project updates by officers, SIG and sub-project leaders. See the slide deck to know about: Jenkins Core, Pipeline, Configuration-as-Code, Security, UX Overhaul, Jenkins Infrastructure, platform support and documentation.
Some stats and numbers
If this section seems to be too long for you, here is some infographic prepared by Tracy Miranda. As you may see, Jenkins is pretty big 🙂
Community. Over the past year we had 5433 contributors in GitHub repositories (committers, reviewers, issue submitters, etc.). We had 1892 unique committers who created 7122 pull requests and 45484 commits, bots excluded. Contributors represent 273 companies and 111 countries, 8% of contributors are recognized as independent. The most active repositories were Jenkins Core and jenkins.io. The most active month was October 2019 when we reached the record high number of contributions: 915 unique contributors, 124 of them were first-timers, thanks to Hacktoberfest!.
Jenkins core. In 2019 Jenkins core had 54 weekly and 13 LTS releases with several hundreds of notable fixes/enhancements. There was a login screen extensibility rework, many update manager and administrative monitors improvements. We also introduced support for user timezones, not speaking of emojis support 🥳. There was also a lot of housekeeping work: better APIs, codebase refresh, cleaning up static analysis warnings and removing deprecated features like Remoting CLI. The core’s components also got major updates. Only Jenkins Remoting got 11 releases with stability improvements and new features like support of inbound connections to headless Jenkins masters. There are also major incoming features like JEP-222: WebSocket Services support, UI look&feel updates, JENKINS-12548: Readonly system configuration support, Docker images for new platforms like Arm. To facilitate further changes we created a new Core pull request reviewers team and added 9 contributors there.
Plugins. There were 2654 plugin releases, and 157 NEW plugins have been hosted in the Update Center. Jenkins ecosystem got a lot of new integrations with Development and DevOps tools. Also, warm welcome back to the Scriptler Plugin which was depublished in 2017 due to security issues. If you are afraid about such plugin numbers and dependency management, there is a new Plugin Installation Manager CLI Tool which should help Jenkins users to manage plugins more efficiently.
Security. It was a hot year for the Jenkins Security Team. There were 5security advisories for the core and 20 – for plugins. In total we disclosed 288 vulnerabilities across the project, including some backlog cleaning for unmaintained plugins. Script Security Plugin was the hottest plugin with 10 critical fixes addressing various sandbox bypass vulnerabilities. Plain text storage and unprotected credentials were the most popular vulnerability type 120 disclosures in 2019. It was made possible by hundreds of reports submitted by contributors after code surveys, special thanks to Viktor Gazdag who reported the most of the issues and became the Jenkins 2019 Security MVP (check out his story here).
Infrastructure. Got Jenkins? If so, you rely on Jenkins update centers, website and issue tracker. All these and many other services are maintained by the Jenkins Infrastructure Team. This year the team handled more than 400 requests in the bugtracker, and many other informal requests. In total, more than 30 people contributed to Jenkins infrastructure this year (website content is excluded). We also deployed 4 new services, migrated 7 services from Azure Container Service to Azure Kubernetes Service and updated many other services. More changes will happen in the next months, and we are looking for new INFRA team members!
Documentation. Only last quarter we had 178 contributors to Jenkins documentation. It includes jenkins.io and other documentation hosted on GitHub, Wiki is not included. There is also ongoing migration plugin documentation from Jenkins Wiki to GitHub (announcement). Since the beginning of the project in Sep 2019, more than 150 plugin were migrated, and they got significant documentation revamp during the migration. You can see the current status https://jenkins-wiki-exporter.jenkins.io/progress. We also work on introducing changelog automation in the project. 123 plugins have already adopted the new changelog tools, powered by Release Drafter. Also, we had more than 60 technical blog posts published on jenkins.io.
Configuration as Code was one of the most popular areas this year. Jenkins Configuration as Code Plugin had more than 30 releases with new features and bug fixes. More than 50 plugins have been also updated in order to offer better configuration-as-code support. As a result, the JCasC Plugin got massive adoption this year (from 2000 to almost 8000 installations), and now it becomes a de-facto standard for managing Jenkins as code. This year we also ran our very first CommunityBridge project devoted to JCasC Schema validation and developer tools.
Events and outreach programs. In 2019 we participated in multiple conferences, including FOSDEM, DevOps World | Jenkins World, SCALE. More than 40 Jenkins Area Meetups were organized across the world, and there were many other meetups devoted to Jenkins. We also kept expanding our outreach programs. In total we had 12 students who participated in Google Summer of Code, Outreachy and newly introduced Community Bridge. We also had the biggest ever Hacktoberfest with 664 pull requests and 102 participants. These outreach programs help us to deliver new features in Jenkins. For example, this year we added Multi-branch Pipeline support for Gitlab and a new Plugin Installation Manager Tool during GSoC, and Outreachy resulted in a new Audit Log Plugin.
Year 2020 will be pretty busy for the Jenkins project. There are many long-overdue changes in the project, which need to happen if we want the project to succeed. As it was written Board elections blogpost, there are many areas to consider: UX revamp, cloud native Jenkins, pluggable storage, etc. In the coming months there will be a lot of discussions in mailing lists and special interest groups, and we invite all teams to work on their roadmaps and to communicate them in the community.
Next month we will participate in FOSDEM, and there will be a Jenkins stand there. On January 31st we will also host a traditional contributor summit in Brussels, where we will talk about next steps for the project, in terms of technical roadmaps and the project governance. If you are interested in Jenkins, stop by at our community booths and join us at the summit! See this thread for more information.
We also plan to continue all outreach programs. At the moment we are looking for Google Summer of Code 2020 mentors and project ideas (announcement), and we will be also interested to consider non-coding projects as a part of other programs like CommunityBridge. We also work on improving contribution guidelines for newcomers and expert contributors. If you are interested, please contact the Advocacy and Outreach SIG.
And even more
This blog post does not provide a full overview of what changed in the project. The Jenkins project consists of more than 2000 plugins and components which are developed by thousands of contributors. Thanks to them, a lot of changes happen in the project every day. We are cordially grateful to everybody who participates in the project, regardless of contribution size. Everything matters: new features, bug fixes, documentation, blog posts, well reported issues, Stackoverflow responses, etc. THANKS A LOT FOR ALL YOUR CONTRIBUTIONS!
So, keep updating Jenkins and exploring new features. And stay tuned, there is much more to come next year!
Jenkins core maintainer and board member. Oleg started using Hudson for Hardware/Embedded projects in 2008 and became an active Jenkins contributor in 2012. Nowadays he leads several Jenkins SIGs, outreach programs (Google Summer of Code, Hacktoberfest) and Jenkins meetups in Switzerland and Russia. Oleg works for CloudBees and focuses on key projects in the community. GitHub Twitter Blog
Outreachy is a program for open source internships that specifically targets people in demographics that are underrepresented in tech. Since 2010 Outreachy has had over 400 participants making contributions to open source projects. Outreachy is one of the most effective programs for improving the diversity of open source communities. For those familiar with Google Summer of Code, Outreachy follows a very similar format.
The Continuous Delivery Foundation is a neutral home for the next generation of continuous delivery collaboration. We know that the greater number of diverse voices we have collaborating, the more effective we are as a community. Which is why we are thrilled to be participating in Outreachy for this upcoming round.
Three of the CD Foundation projects: Jenkins, Jenkins X and Tekton are offering Outreachy internship projects. The Jenkins project has participated in the previous 2 rounds of Outreachy, having a total of 4 Outreachy interns working with the community on the Jenkins Audit Log Plugin. Jenkins mentor Matt Sicker shares in this post “Outreachy has helped open my eyes to the struggles that developers from around the world are dealing with which can be improved upon to help expand our communities. For example, many countries do not have reliable internet or electricity, so the use of synchronous videoconferencing and other heavyweight, synchronous processes common to more corporate-style development are inadequate in this international context.”
In that way Outreachy is also beneficial to the mentors participating. The actual tech contributions are a bonus side effect. Jenkins participates in the program with no expectation that the interns remain part of the community – but takes a wider, long term view that this generally improves open source and tech communities as a whole. Tracy Miranda, Outreachy coordinator for the Jenkins project says “As of this year I know of 2 Outreachy alumni (non-Jenkins projects) who were hired by my employer and both mention the Outreachy program as an important stepping stone in their career journeys.”
Here are the details of this round’s CD Foundation projects which we are looking for interns for. Please help us spread the word.
Kara de la Marck, the Jenkins X Outreachy coordinator can personally speak to the benefits of the program: “Outreachy is a fantastic mentoring program that helps to onboard new contributors to a project and to open source more generally. Many participants go on to become long term contributors to open source. As an alumna, I have carried forward a deep appreciation of open source as an enabler of global collaboration, technological innovation, and community. I’m incredibly happy to welcome Outreachy participants to Jenkins X.”
Please help us spread the word, and we look forward to working with Outreachy interns and welcoming them into our community.
Jenkins Community Celebrates 15 years of Continuous Delivery Automation and Innovation at DevOps World | Jenkins World
DEVOPS WORLD | JENKINS WORLD, SAN FRANCISCO – AUGUST 14, 2019 – The Jenkins project, comprised of the community of practitioners using Jenkins®,
today celebrated its 15th birthday at DevOps
World | Jenkins World with a recap of milestones showcasing
the community’s growth and the project’s defining impact on the global software industry.
Jenkins is the world’s leading open source
automation server, used by companies large and small to implement continuous
integration (CI) and continuous delivery (CD). Originally developed in 2004 and
called Hudson, Jenkins’ impact has grown consistently over the years to the
point where experts regularly describe Jenkins as the de facto tool for CI/CD.
So far this year, the Jenkins project has been
a key driver in the formation of the Continuous
Delivery Foundation,
has continued to experience strong uptake in the use of Jenkins and will
recognize key contributors to the Jenkins project around the globe during
Thursday’s keynote session at DevOps World | Jenkins World.
In
establishing the Continuous
Delivery Foundation, the Jenkins community worked with The
Linux Foundation, CloudBees, Google and Netflix to create a new foundation for
the diverse CI/CD space. In addition to Jenkins, the Continuous Delivery
Foundation was established with several other CI/CD open source projects,
including Jenkins X, Spinnaker and Tekton. It serves as a vehicle to develop, nurture and promote open source
projects, best practices and industry specifications related to continuous
delivery.
The
Continuous Delivery Foundation fosters vendor-neutral collaboration between the
industry’s top developers, end users and vendors to further CI/CD best
practices and industry specifications. Its mission is to grow and sustain
projects that are part of the broad and growing continuous delivery ecosystem.
“This has been a great year for Jenkins, the
Continuous Delivery Foundation and open source collaboration as a whole,” said
Chris Aniszczyk, vice president at the Linux Foundation. “We all share a common
mission – to support community-based development of projects that advance the
state of software delivery. The Jenkins project has been squarely behind this
effort from day one and today the community is stronger than ever.”
Also
playing a key role in Jenkins’ transition to the CDF was CloudBees’ Tracy
Miranda. Miranda took on the dual roles of CloudBees director of open source
community and member of the governing board of the CDF. “CD is becoming a
differentiator for organizations in every industry, yet adoption remains
challenging. It’s an industry-wide problem that needs an industry-wide
solution. From the CloudBees perspective, we see it as critical to have a
neutral foundation where all agents of change can collaborate and contribute
openly,” said Miranda. “Looking ahead to the next 15 years, we need to solve the complexity of CD adoption. With
the CDF, we are well-equipped to do this in open source – building on top of
all that we have learned in the Jenkins community over the years.”
During
the period from July 1, 2018, through June 30, 2019, the Jenkins project
achieved these milestones:
46% growth in active Jenkins installations1
reporting usage data was in the period August 1, 2018 – July 31, 2019
The community experienced approximately 46 percent growth in active
installations, reaching 265,956 installations as of July 31, 2019, compared to
182,236 installations as of August 1, 2018. Active installations are defined as
Jenkins instances that report usage information back to the Jenkins project.
This number is not representative of the total Jenkins instances in use
worldwide; that number is significantly greater.
Approximately 15.8 million Jenkins developers A recent Datanyze analysis of the CI vendor landscape showed that about 66
percent of continuous integration is being run on Jenkins. With an estimated 24
million developers, globally, according to Evans Data in its 2019 Global
Developer Population and Demographics Study, approximately 15.8 million developers are
using Jenkins.
254% growth in Jenkins Pipeline jobs Finally, the combined number of defined Jenkins jobs increased during this same period from 19,946,119 in July 2018 to 30,281,905, or 52 percent growth. Specifically, Jenkins Pipeline jobs grew 254 percent in the same period. The dramatic growth in Jenkins Pipeline jobs demonstrates that organizations are accelerating their investment in modern software pipeline automation practices with Jenkins.
“Over the past 15 years, the Jenkins project has revolutionized the way software is built and delivered,” said Jenkins creator Kohsuke Kawaguchi, who also serves as chief scientist at CloudBees. “We have touched every industry and made a difference to every software team in the world.”
1The Jenkins community tracks statistics from active Jenkins installations that transmit usage information back to the project. The numbers do not represent a majority of Jenkins installations, only those who choose to report. Therefore, the numbers are conservative.
About the Continuous Delivery Foundation Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. The Continuous Delivery Foundation (CDF) is a Linux Foundation initiative that serves as the vendor-neutral home for many of the fastest-growing projects, including Jenkins, Jenkins X, Spinnaker, and Tekton. The CDF fosters collaboration between the industry’s top developers, end users and vendors to further continuous delivery best practices. For more information about the CDF, please visit https://cd.foundation.
Every year before the DevOps World | Jenkins World conference, Jenkins contributors gather for a contributor summit. Earlier this year, the CD Foundation became the new home for Jenkins as well as Jenkins X, Tekton and Spinnaker projects. CD Foundation serves as the new home for many of the fastest-growing projects for continuous delivery as well as a neutral home for collaboration in the CI/CD space. In that spirit of collaboration, this year’s contributor summit is being expanded to be a CDF Contributor Summit.
CDF Contributor Summit will be held on Monday August 12, 2019 in San Francisco, USA just before DevOps World | Jenkins World. It is a free event open to contributors of the open source projects. So far we will have community members from the Jenkins, Jenkins X and Tekton projects attending the summit.
The summit brings together community members to learn, meet and help shape the future of the projects. In the CDF community we value all types and sizes of contributions and love to welcome new participants who want to contribute to one or more projects.
The morning portion of the summit will consist of presentations by core committers of the projects. Presentations will highlight what each effort is about and what community members can do to help. We will cover a range of topics from technical aspects to community topics.
In the afternoon we will break into Birds of a Feather table for in-depth discussion and collaboration on different topics of interest. Bring your laptop, come prepared with questions and ideas, and be ready to meet and get coding with other contributors.
Agenda: (tentative)
9:00 am – Kickoff & Welcome with coffee/pastries
10:00 am – Project Updates
12:00 pm – Lunch
1:00 pm – BoF/Unconference
3:00 pm – Break
3:30 pm – BoF/Unconference
4:30 – Ignite Talks
5:00 pm – Wrap-up
To join the summit, please sign up with the main project you contribute to or are interested in contributing to:
