Recent Blog Posts

We are happy to announce that the Jenkins project has achieved the graduated status in the Continuous Delivery Foundation (CDF). This status is officially effective Aug 03, 2020. Jenkins is the first project to graduate in the CD Foundation. Thanks to all contributors who made our graduation possible! In this article, we will discuss what the CD Foundation membership and graduation mean to the Jenkins community. We will also talk about what changed in Jenkins as a part of the graduation, and what are the future steps for the project. To know more about the Jenkins graduation, see also the announcement on the CD Foundation website. Also see the special edition of the CD Foundation Newsletter for Jenkins user success stories and some surprise content. The press release is available here. How does CDF membership help us? About 18 months ago, Jenkins became one of the CDF founding projects, along with Jenkins X, Spinnaker and Tekton. A new foundation was formed to provide a vendor-neutral home for open source projects used for Continuous Delivery and Continuous Integration. Special interest groups were started to foster collaboration between projects and end user companies, most notably: Interoperability, MLOps and Security SIGs. Also, a Community Ambassador role was created to organize local meetups and to provide public-facing community representatives. Many former Jenkins Ambassadors and other contributors are now CDF Ambassadors, and they promote Jenkins and other projects there. Thanks to this membership we addressed key project infrastructure needs. Starting from Jan 2020, CDF covers a significant part of the infrastructure costs including our services and CI/CD instances running on Microsoft Azure. The CD Foundation provided us with legal assistance required to get code signing keys for the Jenkins project. Thanks to that, we were able to switch to a new Jenkins Release Infrastructure. The foundation sponsors the Zoom account we use for Jenkins Online Meetups and community meetings. In the future we will continue to review ways of reducing maintenance overhead by switching some of our self-hosted services to equivalents provided by the Linux Foundation to CDF members. Another important CDF membership benefit is community outreach and marketing. It helped us to establish connections with other CI/CD projects and end user companies. Through the foundation we have access to the DevStats service that provides community contribution statistics and helps us track trends and discover areas for improvement. On the marketing side, the foundation organizes webinars, podcasts and newsletters. Jenkins is regularly represented there. The CD Foundation also runs the meetup.com professional account which is used by local Jenkins communities for CI/CD and Jenkins Area Meetups. Last but not least, the Jenkins community is also represented at virtual conferences where CDF has a booth. All of that helps to grow Jenkins visibility and to highlight new features and initiatives in the project. Why did we graduate? The Jenkins project has a long history of open governance which is a key part of today’s project success. Starting from 2011, the project has introduced the governance meeting which are open to anyone. Most of the discussions and decision making happen publicly in the mailing lists. In 2015 we introduced teams, sub-projects and officer roles. In 2017 we introduced the Jenkins Enhancement Proposal process which helped us to make the key architecture and governance decisions more open and transparent to the community and the Jenkins users. In 2018 we introduced special interest groups that focus on community needs. In 2019 we have expanded the Jenkins governance board so that it got more bandwidth to facilitate initiatives in the project. Since the Jenkins project inception 15 years ago, it has been steadily growing. Now it has millions of users and thousands of contributors. In 2019 it has seen 5,433 contributors from 111 countries and 272 companies, 67 core and 2,654 plugin releases, 45,484 commits, 7,000+ pull requests. In 2020 Q2 the project has seen 21% growth in pull requests numbers compared to 2019 Q2, bots excluded. One may say that the Jenkins project already has everything needed to succeed. It is a result of continuous work by many community members, and this work will never end as long as the project remains active. Like in any other industry, the CI/CD ecosystem changes every day and sets new expectations from the automation tools in this domain. Just as the tools evolve, open source communities need to evolve so that they can address expectations, and onboard more users and contributors. The CDF graduation process helped us to discover opportunities for improvement, and address them. We reviewed the project processes and compared them with the Graduated Project criteria defined in the CDF project lifecycle. Based on this review, we made changes in our processes and documentation. It should improve the experience of Jenkins users, and help to make the Jenkins community more welcoming to existing and newcomer contributors. What changed for the project? Below you can find a few key changes we have applied during the graduation process: Public roadmap We introduced a new public roadmap for the Jenkins project. This roadmap aggregates key initiatives in all community areas: features, infrastructure, documentation, community, etc. It makes the project more transparent to all Jenkins users and adopters, and at the same time helps potential contributors find the hot areas and opportunities for contribution. The roadmap is driven by the Jenkins community and it has a fully public process documented in jep:14[]. More details about the public roadmap are coming next week, stay tuned for a separate blogpost. On July 10th we had an online contributor meetup about the roadmap and you can find more information in its materials ( slides, video recording). User Documentation Jenkins Weekly Release line is now documented on our website ( here). We have also reworked the downloads page and added guidelines explaining how to verify downloads. A new list of Jenkins adopters was introduced on jenkins.io. This list highlights Jenkins users and references their case studies and success stories, including ones submitted through the Jenkins Is The Way portal. Please do not hesitate to add your company there! Community We passed the Core Infrastructure Initiative (CII) certification. This certification helps us to verify compliance with open source best practices and to make adjustments in the project (see the bullets below). It also provides Jenkins users and adopters with a public summary about compliance with each best practice. Details are on the Jenkins core page. Jenkins Code of Conduct was updated to the new version of Contributor Covenant. In particular, it sets best practices of behavior in the community, and expands definitions of unacceptable behavior. The default Jenkins contributing template was updated to cover more common cases for plugin contributors. This page provides links to the Participate and Contribute guidelines hosted on our website, and helps potential contributors to easily access the documentation. The Jenkins Core maintainer guide was updated to include maintenance and issues triage guidelines. It should help us to deliver quality releases and to timely triage and address issues reported by Jenkins users. What’s next? It an honor to be the first project to reach the graduated stage in the Continuous Delivery Foundation, but it is also a great responsibility for the project. As a project, we plan to continue participating in the CDF activities and to work with other projects and end users to maintain the Jenkins' leader role in the CI/CD space. We encourage everyone to join the project and participate in evolving the Jenkins project and driving its roadmap. It does not necessarily mean committing code or documentation patches; user feedback is also very important to the project. If you are interested to contribute or to share your feedback, please contact us in the Jenkins community channels ( mailing lists, chats)! Acknowledgements CDF graduation work was a major effort in the Jenkins community. Congratulations and thanks to the dozens of contributors who made our graduation possible. I would like to thank Alex Earl, Alyssa Tong, Dan Lorenc, Daniel Beck, Jeff Thompson, Marky Jackson, Mark Waite, Olivier Vernin, Tim Jacomb, Tracy Miranda, Ullrich Hafner, Wadeck Follonier, and all other contributors who helped with reviews and provided their feedback! Also thanks to the Continuous Delivery Foundation marketing team (Jacqueline Salinas, Jesse Casman and Roxanne Joncas) for their work on promoting the Jenkins project and, specifically, its graduation. About the Continuous Delivery Foundation The Continuous Delivery Foundation (CDF) serves as the vendor-neutral home of many of the fastest-growing projects for continuous delivery, including Jenkins, Jenkins X, Tekton, and Spinnaker, as well as fosters collaboration between the industry’s top developers, end users and vendors to further continuous delivery best practices. The CDF is part of the Linux Foundation, a nonprofit organization. For more information about the foundation, please visit its website. More information To know more about the Jenkins graduation in the Continuous Delivery Foundation, see the announcement on the CD Foundation website. Also see the special edition of the CD Foundation Newsletter for Jenkins user success stories and some surprise content. The press release is available here.

As a developer, I usually use Jenkins like this: Find a job which is related with my current work Trigger that job Check the output of the build log Sometimes, I might need to check the update center. Maybe a new plugin is needed, or I need to update an existing plugin. Or, I want to upload a plugin from my computer. For all these cases, I just don’t need a UI or even a browser. I like to use a CLI to complete most of my tasks. For example, I use kubectl to manage my Kubernetes cluster, to create or modify the kubernetes resources. So, I start to think, 'Why not use a CLI to manage my Jenkins?'. Why create a new one? First, I almost forgot about the existing Jenkins CLI, written in Java. Let me introduce how to use that one. Visit Jenkins page from http://localhost:8080/jenkins/cli/ . You’ll see a command like java -jar jenkins-cli.jar -s http://localhost:8080/jenkins/ help. So, a jar file needs to be download. We can use this command to complete this task wget http://localhost:8080/jenkins/jnlpJars/jenkins-cli.jar . Now you can see that this is not a Linux-style CLI. Please consider some points below: The users must have a JRE. This is not convenient for developers who don’t use Java. The CLI is too wordy. We always need to type java -jar jenkins-cli.jar -s http://localhost:8080/jenkins/ as the initial command. Cannot install it by some popular package manager, like brew or yum. Of course, the Java CLI client is more native with Jenkins. But I’d like to use this more easily. So I decided to create a new CLI tool which would be written in Go and which would natively run on modern platforms. That’s the story of creating jcli. Features Easy to maintain config file for jcli Multiple Jenkins support Plugins management (list, search, install, upload) Job management (search, build, log) Open your Jenkins with a browser Restart your Jenkins Connection with proxy support How to get it? You can clone jcli from the jenkins-cli repo. For now, we support these three most popular OS platforms: MacOS, Linux, and Windows. MacOS You can use brew to install jcli. brew tap jenkins-zh/jcli brew install jcli Linux It’s very simple to install jcli into your Linux OS. Just need to execute a command line at below: curl -L https://github.com/jenkins-zh/jenkins-cli/releases/latest/download/jcli-linux-amd64.tar.gz|tar xzv sudo mv jcli /usr/local/bin/ Windows You can find the latest version by clicking here. Then download the tar file, cp the uncompressed jcli directory into your system path. How to get started? It’s very simple to use this. Once you get jcli on your computer, use this command to generate a sample configuration: $ jcli config generate current: yourServer jenkins_servers: - name: yourServer url: http://localhost:8080/jenkins username: admin token: 111e3a2f0231198855dceaff96f20540a9 proxy: "" proxyAuth: "" # Goto 'http://localhost:8080/jenkins/me/configure', then you can generate your token. In most cases, you should modify three fields which are url, username and token. OK, I believe you’re ready. Please check whether you install the github plugin in your Jenkins: jcli plugin list --filter name=github That’s the end. It’s still in very early development stage. Any contribution is welcome.

Jenkins stores all generated artifacts on the controller server filesystem. This presents a couple of challenges especially when you try to run Jenkins in the cloud: As the number of artifacts grow, your Jenkins controller will run out of disk space. Eventually, performance can be impacted. Frequent transfer of files between agents and controller may cause load, CPU or network issues which are always hard to diagnose. Several existing plugins allow you to manage your artifacts externally. To use these plugins, you need to know how they work and perform specific steps in your job’s configuration. And if you are new to Jenkins, you may find it hard to follow existing samples in Jenkins tutorial like Recording tests and artifacts. So, if you are running Jenkins in Azure, you can consider automatically managing new artifacts on Azure Storage. The new Azure Artifact Management plugin allows you to store artifacts in Azure blob storage and simplify your existing Jenkins jobs that contain Jenkins general artifacts management steps. This approach will give you all the advantages of a cloud storage, with less effort on your part to maintain your Jenkins instance. Configuration Azure storage account First, you need to have an Azure Storage account. You can skip this section if you already have one. Otherwise, create an Azure storage account for storing your artifacts. Follow this tutorial to quickly create one. Then navigate to Access keys in the Settings section to get the storage account name and one of its keys. Existing Jenkins instance For existing Jenkins instance, make sure you install the Azure Artifact Manager plugin. Then you can go to your Jenkins System Configuration page and locate the Artifact Management for Builds section. Select the Add button to configure an Azure Artifact Storage. Fill in the following parameters: Storage Type: Azure storage supports several storage types like blob, file, queue etc. This plugin currently supports blob storage only. Storage Credentials: Credentials used to authenticate with Azure storage. If you do not have an existing Azure storage credential in you Jenkins credential store, click the Add button and choose Microsoft Azure Storage kind to create one. Azure Container Name: The container under which to keep your artifacts. If the container name does not exist in the blob, this plugin automatically creates one for you when artifacts are uploaded to the blob. Base Prefix: Prefix added to your artifact paths stored in your container, a forward slash will be parsed as a folder. In the following screenshot, all your artifacts will be stored in the “staging” folder in the container “Jenkins”. New Jenkins instance If you need to create a new Jenkins controller, follow this tutorial to quickly create an Jenkins instance on Azure. In the Integration Settings section, you can now set up Azure Artifact Manager directly. Note that you can change any of the configuration after your Jenkins instance is created. Azure storage account and credential, in this case, are still prerequisites. Usage Jenkins Pipeline Here are a few commonly used artifact related steps in pipeline jobs; all are supported to push artifacts to the Azure Storage blob specified. You can use archiveArtifacts step to archive target artifacts into Azure storage. For more details about archiveArtifacts step, see the Jenkins archiveArtifacts setp documentation. node { //... stage('Archive') { archiveArtifacts "pattern" } } You can use the unarchive step to retrieve the artifacts from Azure storage. For more details about unarchive step, please see unarchive step documentation. node { //... stage('Unarchive') { unarchive mapping: ["pattern": '.'] } } To save a set of files so that you can use them later in the same build (generally on another node or workspace), you can use stash step to store files into Azure storage for later use. Stash step documentation can be found here. node { //... stash name: 'name', includes: '*' } You can use unstash step to retrieve the files saved with stash step from Azure storage to the local workspace. Unstash documentation can be found here. node { //... unstash 'name' } FreeStyle Job For a FreeStyle Jenkins job, you can use Archive the artifacts step in Post-build Actions to upload the target artifacts into Azure storage. This Azure Artifact Manager plugin is also compatible with some other popular management plugins, such as the Copy Artifact plugin. You can still use these plugins without changing anything. Troubleshooting If you have any problems or suggestions when using Azure Artifact Manager plugin, you can file a ticket on Jenkins JIRA for the azure-artifact-manager-plugin component. Conclusion The Azure Artifact Manager enables a more cloud-native Jenkins. This is the first step in the Cloud Native project. We have a long way to go to get Jenkins to run on cloud environments as a true “Cloud Native” application. We need help and welcome your participation and contributions to make Jenkins better. Please start contributing and/or give us feedback!

Since 2017, I started to do some contributions to the Jenkins community. As a beginner, translation might be the easiest way to help the project. You don’t need to understand the whole context, even to create a ticket in the issue tracker system. Improvement of localization usually is minor. But some problems occurred soon, there isn’t a native speaker of Chinese that could review my PRs. So, sometimes my PRs are delayed from being merged into master. Some contributors told me that I can start a thread at the mailing list. Normally, discussing at the mailing list is the open source community way. We got a lot of ideas for the localization from there. As a result, we achieved some goals that I’d like to share here. JEP-216 Previously, language localization files were distributed in core and in each plugin. For this proposal, each language has a single localization plugin, such as Chinese Localization plugin. Finally, Localization Support Plugin and Chinese Localization plugin are able to support all types of localization resource files. From the plugins website, you can see that there are already 13 000 installations. We removed all Chinese localization files at the PR-4008. I really appreciate Daniel Beck for helping me to add localization support, Liam Newman helping me to review JEP-216, and many other community members. Chinese Localization SIG We believe that this SIG could help to improve Jenkins experience for Chinese users and gather more contributors from China. This SIG is responsible for maintaining the Chinese Jenkins website, promoting the Jenkins community in China in the social media with WeChat account. We publish translated blog articles, Jenkins release notes, JAM or other events at the WeChat account. For now, there are 1800 followers that can read our news from the last half a year. Especially, I want to say thanks to Wang Donghui, Zhai Zhijun, and other contributors. They did a lot of contributions. I wish I could see more and more folks join us.

Implementing DevSecOps practices at the enterprise scale is challenging. With multiple programming languages, automated testing frameworks, and security compliance tools being used by different applications within your organization, it becomes difficult to build and maintain pipelines for each team. Most pipelines are going to follow the same generic workflow regardless of which specific tech stack is employed by an application. The Templating Engine Plugin (abbreviated as JTE for Jenkins Templating Engine) allows you to capture this efficiency by creating tool-agnostic, templated workflows to be reused by every team. As technology consultants with clients in both the public and private sectors, at Booz Allen we found ourselves building DevSecOps pipelines from scratch for every new project. Through developing the Jenkins Templating Engine, we’ve seen pipeline development decrease from months to days now that we can reuse tool integrations while bringing a new level of governance to Jenkins pipelines. Pipeline Templating Organizations benefit from letting application developers focus on what they do best: building applications. Supporting this means building a centralized DevOps team responsible for maintaining platform infrastructure and creating CI/CD pipelines utilized by development teams. With the rise of microservice-based architectures, a centralized DevOps teams can support many different development teams simultaneously; all of whom may be leveraging different programming languages and automated testing tools. While the tools may differ between development teams, the workflow is often the same: unit test, static code analysis, build and publish an artifact, deploy it, and then perform different types of testing against the deployed application. The Templating Engine Plugin allows you to remove the Jenkinsfile from each repository by defining a common workflow for teams to inherit. Instead of an entire pipeline definition in each repository, teams supply a configuration file specifying which tools to use for the workflow. JTE in Action Let’s walk through a bare bones example to demonstrate the reusability of templates: Example Pipeline Template: unit_test() build() static_code_analysis() Templates leverage Steps contributed by Libraries to outline a workflow teams must implement. While a template does get executed just like any other Jenkinsfile (meaning that the standard scripted and declarative syntax is supported), the goal of a template should be to read like plain English and avoid any technical implementation. Leveraging templates in this way lets you separate the business logic (what should happen when) of your pipeline from the technical implementation (what’s actually going to happen). The result of this is a CI/CD pipeline that’s proven to be significantly easier to manage when supporting multiple teams simultaneously. The steps outlined by this template ( unit_test, build, and static_code_analysis) have been named generically on purpose. This way teams can specify different libraries to use while sharing the same pipeline. Implementing the Template Implementing a shareable pipeline with the Templating Engine requires a few key components: Pipeline Template : Outline the workflow to be performed Libraries : Provide technical implementations of the steps of the workflow Configuration Files : Specify which libraries to use and their configuration Step 1: Create a Pipeline Configuration Repository A Pipeline Configuration Repository is used to store common configurations and pipeline templates inherited by teams. This example Pipeline Configuration Repository will later be configured as part of a Governance Tier : the mechanism in JTE that allows you to build hierarchical configurations representing your organization. A Governance Tier holds three things: Pipeline Templates A list of Library Sources The tier’s configuration file ( pipeline_config.groovy) The pipeline templates and the configuration file for a Governance Tier are stored in the pipeline configuration repository. When configuring the Governance Tier in Jenkins, you will provide a source code management location for a repository that contains the above components as well as the base directory where these artifacts can be found. Step 2: Create the Pipeline Template Next, we’ll create a Jenkinsfile for the Governance Tier. In JTE, the Jenkinsfile is the default pipeline template that an execution will use. Jenkinsfile unit_test() build() static_code_analysis() Step 3: Create the Libraries The Templating Engine Plugin has implemented a version of Jenkins Shared Libraries to enhance the reusability of libraries. A library is a root directory within a source code repository that has been configured as a Library Source on a Governance Tier. In our example, the pipeline template needs to perform unit testing, package an artifact, and run static code analysis. Let’s assume that we have some teams using gradle and some teams using maven to build and test their application but they will both use SonarQube to perform static code analysis. In this scenario, we should create gradle, maven, and sonarqube libraries. |- gradle/ \-- build.groovy \-- unit_test.groovy |- maven/ \-- build.groovy \-- unit_test.groovy |- sonarqube/ \-- static_code_analysis.groovy Step 4: Implement the Steps Implementing a library step is exactly the same as just writing regular global variables as part of the default Jenkins Shared Libraries. For the purposes of this demonstration, we will just have each step print out the step name and contributing library. gradle/build.groovy void call(){ println "gradle: build()" } Read more about Library Development within JTE. Step 5: Create the Configuration Files The configuration file for JTE is named pipeline_config.groovy. In the Governance Tier we’ll create a configuration file specifying common configurations between the applications. In this case, both applications are using the sonarqube library: pipeline_config.groovy libraries{ merge = true // allow individual apps to contribute additional libraries sonarqube } Next, we’ll create two more repositories representing the maven and gradle applications. Within those repositories all we’ll need is an application-specific pipeline_config.groovy file. These repositories both contain an application pipeline_config.groovy configuration file. maven app: pipeline_config.groovy libraries{ maven } gradle app: pipeline_config.groovy libraries{ gradle } Step 6: Configure the Governance Tier in Jenkins Now that we have a Pipeline Configuration Repository and a Library Source Repository, we can configure a Governance Tier in Jenkins: This configuration shown in the image above can be found under Manage Jenkins >> Configure System Through the Templating Engine, you can create a pipeline governance hierarchy matching your organization’s taxonomy by representing this structure via Folders in Jenkins. Step 7: Create a Multibranch Pipeline for Both Applications When creating Multibranch Pipeline Projects for each app, the Templating Engine plugin supplies a new Project Recognizer called Jenkins Templating Engine. This sets the project to use the Templating Engine framework for all branches within the repository. You can also set the Jenkins Templating Engine project recognizer for a GitHub Organization project, enabling you to easily share the same pipeline across an entire Github Organization! Step 8: Run the Pipelines That’s it! Now, both applications will leverage the exact same pipeline template while having the flexibility to select which tools should be used during each phase of the workflow. Below is sample output from the console log from both applications pipeline runs: Gradle: [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-configuration [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-app-gradle.git [JTE] Loading Library sonarqube from git https://github.com/steven-terrana/example-jte-libraries.git [JTE] Loading Library gradle from git https://github.com/steven-terrana/example-jte-libraries.git ... [JTE] Obtained Template Jenkinsfile from git https://github.com/steven-terrana/example-jte-configuration [JTE][Step - gradle/unit_test] [Pipeline] echo gradle: unit_test() [JTE][Step - gradle/build] [Pipeline] echo gradle: build() [JTE][Step - sonarqube/static_code_analysis] [Pipeline] echo sonarqube: static_code_analysis() [Pipeline] End of Pipeline Maven: [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-configuration [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-app-maven.git [JTE] Loading Library sonarqube from git https://github.com/steven-terrana/example-jte-libraries.git [JTE] Loading Library maven from git https://github.com/steven-terrana/example-jte-libraries.git ... [JTE] Obtained Template Jenkinsfile from git https://github.com/steven-terrana/example-jte-configuration [JTE][Step - maven/unit_test] [Pipeline] echo maven: unit_test() [JTE][Step - maven/build] [Pipeline] echo maven: build() [JTE][Step - sonarqube/static_code_analysis] [Pipeline] echo sonarqube: static_code_analysis() [Pipeline] End of Pipeline Benefits of the Templating Engine Apply Organizational Governance Leveraging the Templating Engine Plugin will allow you to define enterprise-scale, approved workflows that can be used by teams regardless of what tools are being used. This top-down approach makes scaling and enforcing DevSecOps principles significantly easier within your organization. Optimize Code Reuse There’s really no need for every team in your organization to figure out how to do the same things over and over again. At Booz Allen, we have seen pipeline development time decrease from months to days as we have continuously reused and expanded upon our Templating Engine library portfolio as part of our Solutions Delivery Platform. Simplify Pipeline Maintainability Often DevOps engineers find themselves building and supporting pipelines for multiple development teams at the same time. By decoupling the workflow from the technical implementation and consolidating the pipeline definition to a centralized location, the Templating Engine plugin allows DevOps engineers to scale much faster. Get Involved! The Templating Engine Plugin has been open sourced and made available in the Jenkins Update Center. We always appreciate feedback and contributions! If you have an interesting use case or would like to ask questions, try the templating-engine-plugin on Gitter. Advanced Features Configuration File Conditional Inheritance Externalize Library Configurations Aspect Oriented LifeCycle Hooks Multiple Pipeline Templates Default Step Implementation Configuration File DSL Sandboxing More Resources For this Demonstration Pipeline Configuration Repository Sample Libraries Sample Maven Repository Sample Gradle Repository Additional Resources Templating Engine Documentation Source Code Booz Allen’s SDP Pipeline Libraries Booz Allen Hamilton

Today Linux Foundation, along with CloudBees, Google, and a number of other companies, launched a new open-source software foundation called Continuous Delivery Foundation (CDF.) The CDF believes in the power of Continuous Delivery, and it aims to foster and sustain the ecosystem of open-source, vendor neutral projects. Jenkins contributors have decided that our project should join this new foundation. This discussion happened over a period of time, with a relatively succinct summary of the motivation comes from here. Now, as a user, what does this mean? First, there will be no big disruption/discontinuity. The same people are still here, no URL is changing, releases will come out like they’ve always been. We will make the decisions the same way as we’ve been making, and pull requests land the same way. Changes will happen continuously over the period of time. This is yet another testament to the maturity and the importance of the Jenkins project in this space. With a quarter million Jenkins running around the globe, it’s truly rocking the world of software development from IoT to games, cloud native webapps to machine learning projects. It makes Jenkins such an obvious, safe choice for anyone seeking open heterogeneous DevOps strategy. The CDF creates a level playing field that is well-understood to organized contributors, which further, translate into more contributors, hence resulting in a better Jenkins, faster. Over the past years, the Jenkins project has been steadily growing more structures that provide this clarity, and this is the newest step on this trajectory. Any serious dev teams are combining multiple tools and services to cover the whole software development spectrum. A lot of work gets reinvented in those teams to integrate those tools together. Jenkins will be working more closely with other projects under the umbrella of the CDF, which would result in better aligned software with less overlap. Our users are practitioners trying to improve the software development process in their organizations. They get that CI/CD/automation which unlocks the productivity that their organizations need, but that’s not always obvious to their organizations as a whole. So our users often struggle to get the necessary support. The CDF will advocate for the practice of Continuous Delivery, and because it’s not coming from a vendor or a project, it will reach the people who can lend that support. So I hope you can see why we are so excited about this! In fact, for us, this is an idea that we’ve been cooking for close to two years. I don’t think I’m exaggerating much to say the whole idea of the CDF started from the Jenkins project. A lot of people have done so much work behind the scene to make this happen. But a few people played such instrumental roles that I have to personally thank them namely, Chris Aniszczyk for his patience and persistence, R. Tyler Croy for cooking and evolving the idea, and Tracy Miranda for bringing this idea into a reality.

The Jenkins project has learned that a company is trying to register "Jenkins" as a trademark in Colombia. This is alarming for us, and we are trying to oppose it. In order to do this effectively, we need to hear from Colombian users of Jenkins. Figure 1. South American visitors to jenkins.io for 2017 The Jenkins project owns a trademark "Jenkins" in the U.S., through a non-profit entity SPI Inc. According to experts on the subject citing the "Washington Convention", our trademark registration in the U.S. does give us some strength in the argument to oppose this. To successfully mount this argument however, we need to be able to show that Jenkins has significant usage and awareness in Colombia. Users, installations, meetups, conference talks, anything of that nature will help. Those of you with the project for a long time might recall that the name "Jenkins" was born because of a trademark issue with Oracle. So we are particularly sensitive to the issue is trademarks. We want to make sure the same tragedy won’t happen again. If you know anything about the usage and the name recognition of Jenkins in Colombia, please let us know by submitting the information here . We know that Jenkins is popular in Colombia, because our website traffic shows that Colombian Jenkins users are the third most frequent visitors to jenkins.io in South America after Brazil and Argentina. This information will be only shared with the Jenkins project board and those involved in the defense, and for the sole purpose of defending the trademark and nothing more. Please help us spread the word. Thanks! El proyecto Jenkins se ha enterado de que una compañía está intentando registrar "Jenkins" como marca registrada en Colombia. Esto es alarmante y estamos tratando de oponernos. Para hacerlo de manera efectiva, necesitamos escuchar a los usuarios colombianos de Jenkins. El proyecto Jenkins posee una marca registrada "Jenkins" en los Estados Unidos, a través de una entidad sin ánimo de lucro SPI Inc. Según los expertos en la materia citando la "Convención de Washington", nuestro registro de marca en los EE.UU. nos da algo de fuerza para oponernos. Sin embargo, para argumentar con éxito, tenemos que ser capaces de demostrar que Jenkins tiene un uso significativo y es conocido en Colombia. Usuarios, instalaciones, encuentros, conferencias, cualquier cosa de ese tipo ayudará. Aquellos que llevan mucho tiempo con el proyecto pueden recordar que el nombre "Jenkins" nació debido a un problema de marca con Oracle. Por lo tanto, estamos especialmente sensibles al tema de las marcas registradas. Queremos asegurarnos de que el mismo problema no vuelva a ocurrir. Si sabe algo sobre el uso y el reconocimiento del nombre Jenkins en Colombia, por favor háganoslo saber enviando la información aquí . Sabemos que Jenkins es popular en Colombia, porque nuestro sitio web de tráfico muestra que los usuarios colombianos de Jenkins son los terceros visitantes más frecuentes a jenkins.io en América del Sur después de Brasil y Argentina. Esta información sólo se compartirá con el comité de proyecto de Jenkins y los involucrados en la defensa, y con el único propósito de defender la marca y nada más. Por favor, ayúdenos a difundir la palabra. ¡Gracias!

On behalf of the GSoC Org Admin team I am happy to announce that we are going to apply to Google Summer of Code (GSoC) again this year. In GSoC high-profile students work in open-source projects for several months under mentorship of organization members. We are looking for mentors and project ideas. So yes, we are looking for you :) Conditions As a mentor, you will be asked to: lead the project in the area of their interest actively participate in the project during student selection, community bonding and coding phases (March - August) work in teams of 2+ mentors per 1 each student dedicate a consistent and significant amount of time, especially during the coding phase ( ~5 hours per week in the team of two mentors) Mentorship does not require strong expertise in Jenkins plugin development. The main objective is to guide students and to get them involved into the Jenkins community. If your mentor team requires any specific expertise, GSoC org admins will do their best in order to find advisors. What do you get? A student, who works within the area of your interest on full-time for several months Joint projects with Jenkins experts, lots of fun and ability to study something together Limited edition of swags from Google and Jenkins project Maybe: Participation in GSoC Mentor Summit in California with expense coverage (depends on project results and per-project quotas) Requirements You are: passionate about Jenkins interested in being a mentor or advisor ready to dedicate time && have no major unavailability periods planned to this summer We expect mentors to be available by email during 75% of working days in the May-August timeframe Your project idea is: about code (though it may and likely should include some documentation and testing work) about Jenkins (plugins, core, infrastructure, etc.) potentially doable by a student in 3-4 months How to apply If you are interested, drop the Email to the Jenkins Developer mailing list with the GSoC2017 prefix. Briefly describe your project idea (a couple of sentences) and required qualifications from students. Examples: GSoC2016, GSoC2017 - current project ideas If you already have a co-mentor(s), please mention them Having several project ideas is fine. Having no specific ideas is also fine. Disclaimer: We cannot guarantee that all projects happen, it depends on student application results and the number of project slots. Links Google Summer of Code page Jenkins GSoC Page GSoC2016 project ideas GSoC2016 page (project results and more info)