Recent Blog Posts

Hello everyone ! This is one of the Jenkins project in GSoC 2020. We are working this new Machine Learning Plugin for this GSoC 2020. This is my story about the community bonding of GSoC 2020. I am happy to share my journey with you. Introducing Myself and my Fantastic 4 Mentors I am Loghi Perinpanayagam from University of Moratuwa. I was selected for GSoC 2020 for Machine Learning Plugin in Jenkins. I am glad to introduce my mentors to this project. I was assigned with four mentors who are really enthusiastic to help me on kicking off this summer of code. Student Loghi Perinpanayagam Mentors Bruno P. Kinoshita Ioannis Moutsatsos Marky Jackson Shivay Lamba How was my preparation last year ? I learned about this open source program in my second year. But atleast I tried last year on a different organization’s project that was related to Data Visualization Recommendation for Data Science. But the problem was I did not contribute as much as this year and was too late in the application process. As usual Machine learning related projects have a lot of competition compared to other projects. I prepared on learning Data visualization in Machine Learning and existing Models for the recommendation system. Finally I wrote a proposal with the SeqToSeq model without much knowledge on neural networks at that time. And I did not communicate much through the dedicated slack channel. That may be one of the reasons for the failure. But the main reason was my latency for GSoC 2019. How did I hurdle GSoC 2020 ? Since the time I realized how open source is needed and helpful for the community, I have been passionate about contributing to open source projects. At the instance, I finished my internship in Bangalore, India in 2019, I immediately focused on participating in GSoC. This is my last year (2020) as a student of my BSc Computer Science life, I wanted to get selected this year as a student. There was a guidance seminar organized by our department, I got to know that Jenkins had opened their project ideas. That was an extremely impressive beginning of my GSoC 2020 journey. I walked through all the draft and accepted projects in the Jenkins.io page. As I am already interested in Machine Learning and I am familiar with Java, I picked the most impressive idea for me that does not have an initial repo. That means I wanted to use my knowledge to think and research a lot with this project. But I had to contribute and want to know about the infrastructure of Jenkins codebase. Because that makes the selection panel easy to pick up the student for the project. Then I repeatedly searched to contribute to Jenkins. I found issues that were easy for me to work from the git plugin and git client plugin. I started to contribute some test issues on git plugin and git client plugin. After I got a clear knowledge on how a plugin works in Jenkins, I started working on the POC with the hint provided in the project idea page. Actually, that was fun to code. Mentors have helped many students during the application process. I was able to do a working POC that had a minimum capability to do the task of the project. Finally mentors opened for proposal submission. I hurried to prepare a draft proposal. After I got reviews from mentors, I started to improve the proposal. At the end of the proposal submission, I was able to deliver a good proposal for this project. As I was curious about this plugin, I dug into more on how to integrate Jupyter notebook with this plugin. I published an medium article as a result of my research during the acceptance waiting period. Results released The result was going to be announced on 4th May, I believed in my project proposal and POC and I got selected for this GSoC 2020. Whoa ! That was a goosebumping moment in my entire life. The feeling was like Something I achieved. As a result of my hard work, I deserved that. For example, I spent 7 days continuously making the POC work without any collision between maven artifacts. Community Bonding After the release of results, I was preparing myself for the community bonding. There are lots of interactions happening between me and mentors than before.I had to update my project page and my profile in Jenkins.io. We had our first meeting with lots of excitement and love on 10th of May. Mentors and I introduced ourselves even though we know each other. We discussed the high level view of GSoC and I asked some questions that I had in my mind. As my plugin was a new repository, most of the discussion was related to the repository and its name. I had to find a name for the new plugin. We had regular conversations about the blogpost and presentations at the end. In the second meeting, We discussed the process for hosting a new plugin in Jenkins, tracking issues with JIRA, blog posts and high level road map for the project. And I suggested some interesting plugin names but they were not matching to the goal of the project, mentors told me to try other names which perfectly describe the project. I was advised to read all the research guidelines and plugin naming conventions. We discussed how code reviews will be done and source code management through the git. After this meeting, our meeting has shifted to the official Jenkins Zoom account. Our third meeting was quite serious about our project planning. I had been preparing my design document for the project with the help of mentors before the meeting day. Hence I got lots of reviews and useful examples for my future work on phase 1. At this point, we decided with the plugin name Machine Learning Plugin which was accepted by all mentors and I created the repo and requested a Jira ticket for the plugin hosting request. We were planning to remind the Jira ticket within the next 3 days. Mentors want me to make sure I updated the Jenkins GSoC page before the community period ends. Lots of discussion carried about the design document that I had been preparing last week before the meeting. Some important points from the meeting notes follows : Define features in the design document Diagrams for the operations How plugin works in distributed environment Code editor library Requirements for the first Plugin release Blog post draft document ToDo works for me for next week Therefore, I had to work hard after this meeting, this made me involved in the project more. I have to put my huge effort to make this opportunity golden. Our team has the willingness to complete this project and will definitely help the Data Science community with this plugin. Kudos to my team for the amazing work so far!!! This was my entire journey until now. Hope you enjoyed it and hope you learned the mistakes I made last year and corrected in this summer. Thanks for reading, and Stay tuned I will be uploading blog posts for those of you interested. Resources and Links Project page Design document

I’m excited to announce that the 'read-only' Jenkins feature is now available for preview. This feature allows restricting configuration UIs and APIs while providing access to essential Jenkins system configuration, diagnostics, and self-monitoring tools through Web UI. Such mode is critical for instances managed as code, e.g. with Jenkins Configuration-as-Code plugin. It is delivered as a part of the jep:224[Readonly system configuration] effort. You will want to use at least Jenkins 2.238 to have all the features mentioned in this post. Read-only Jenkins currently allows users to have access to: job configuration system configuration plugin manager system logs cloud configuration agent configuration agent logs For more planned integrations see the jira:JENKINS-12548[] epic. Read-only Jenkins is split into three permissions: Job/ExtendedRead - Read-only access to job configurations existed since 2009 but the UI didn’t do anything to indicate to the users that they couldn’t edit the job configuration page. This has now been adapted to the new read-only engine. Agent/ExtendedRead - Read-only access to agent configurations existed since 2013 but it was undocumented and only allowed access to API and no UI UI support added in Jenkins 2.238 Overall/SystemRead - Read-only access to Jenkins system configuration. It is very useful for Jenkins instances managed as code, e.g. with help of the Jenkins Configuration as Code Plugin. Introduced in Jenkins 2.222 as a part of jep:224[Readonly system configuration] You can selectively grant the permission(s) as you wish. Why do I want this? Given the rise of the configuration-as-code plugin a lot of Jenkins instances are fully managed as code, which means that no changes are allowed through the UI. The problem with this is you don’t know when new plugin versions are available and in order to see what other configuration options are available to a plugin you currently need the 'Administer' permission. Read-only access to system administration information allows users who are not administrators to more easily debug build issues. For example, given a 'Jenkins' error message in a build the user can check: which plugins are installed the version of the plugin This can allow the user to solve their issue themselves and makes it easier for the user to report an issue with a plugin directly to the maintainers. What can I expect All built in UI controls have been adapted to clearly distinguish between an editable control and a control you don’t have permission to edit: Editable: Non editable: Note: there are other controls such as in the credentials and pipeline plugins that have not been updated yet. Action buttons, (Such as 'Save' and 'Apply') have been hidden in most cases. Work will continue on read-only configuration. Some plugins need support added and certain controls could have some improvements done to render better. How can I use it? These permissions are currently available in beta and for now disabled by default. You can enable them by installing the Extended read permission plugin v3.2 or above. Then you will need to add the following permissions to a user / group depending on your use case: Overall/SystemRead Job/ExtendedRead Agent/ExtendedRead Note: You will need to set the Overall/Read and Job/Read permissions as well. You might want to consider creating a role containing the required permissions. Here is an example using the Configuration as Code plugin and the Folder-based Authorization Strategy plugin : jenkins: authorizationStrategy: folderBased: globalRoles: - name: "admin" permissions: - id: "Overall/Administer" sids: - "admin" - name: "global read" permissions: - id: "Agent/ExtendedRead" - id: "Overall/SystemRead" - id: "Overall/Read" - id: "Job/Read" - id: "Job/ExtendedRead" sids: - "reader" I can’t see a configuration that I think should be allowed Most of Jenkins itself has been updated to support read-only Jenkins, but not very many plugins. Please create an enhancement issue on the plugins issue tracker. If the plugin uses Jira to track issues, then you can add it to the jira:JENKINS-12548[] epic. How do I update my plugin to support it See the Read only view section of the developer documentation. What’s next In this release we introduce a foundation feature which is already supported in all key Jenkins core controls and in some plugins. There are many plugins which contribute to global configurations and diagnostics which still need to be adapted to support the new mode. We will keep working on this feature and its adoption so that the next LTS baseline in September provides a full-fledged user experience for Jenkins admins. System read permission is a featured project in the UI/UX Hackfest happening May 25-29 2020. If you want to get involved please check it out!

This event is over, thanks a lot to all contributors! Please the event page for results. On behalf of the Jenkins User Experience, Documentation and Advocacy and Outreach special interest groups, we are happy to announce the online UI/UX hackfest on May 25-29! Everyone is welcome to participate, regardless of their Jenkins development experience. The goal is to get together and work on improving Jenkins user experience, including but not limited to user interface and user documentation. We also invite you to share experiences about Jenkins and to participate in UX testing. The event follows the Jenkins is the Way theme and the most active contributors will get special edition swag and prizes! Event plan This hackfest is NOT a hackathon. We do not expect participants to dedicate all their time during the event timeframe, but hop-in/hop-out as their time allows. Everybody can spend as much time as they are willing to dedicate. Spending a few days or just a few hours is fine, any contributions matter regardless of their size. Jenkins development experience is not required, we have newcomer-friendly stories for those who want to start contributing to the project. We will also have a 24/7 jenkinsci/hackfest Gitter chat for Q&A and coordination between contributors. There will be 3 main tracks : User Interface - Improve look&feel and accessibility for Jenkins users, work on new read-only interface for instances managed with configuration as code, create and update Jenkins themes, and many other topics. This track is coordinated by the UX SIG. User Documentation - Improve and create new user documentation, tutorials and solution pages. Also, there is ongoing documentation migration from Wiki to jenkins.io and plugin repositories. This track is coordinated by the Documentation SIG. Spread the word - Write user stories for Jenkins Is The Way site and the Jenkins blog, post about your Jenkins user experience and new features, record overview and HOWTO videos, etc. This track is coordinated by the Advocacy and Outreach SIG. We are working on publishing project ideas and issues for the listed tracks. The current list can be found on the UI / UX hackfest event page, this list will be finalized by the beginning of the hackfest. You are welcome to propose your own projects within the User Experience theme. During the event, we will organize online meetups and ad-hoc training sessions in different timezones. All these sessions will be recorded and shared on our YouTube channel. There are no mandatory sessions you must attend, you are welcome to join ones remotely or watch the recordings. After the event we will invite participants to demo their projects at online meetings or recorded sessions. Registration This event is over, thanks a lot to all contributors! P.S: Note that the registration form has a question top 3 things we could change in Jenkins to improve your user experience. We would appreciate your response there! Contacts Please use the following contacts to contact organizers: Gitter chat Mailing list Resources Event Page Registration form. Project ideas (work-in-progress). The full list will be published by the beginning of the event. Frequently Asked Questions Contributing to Jenkins Code of Conduct Swag and Prizes Thanks to our sponsors ( CloudBees, Inc. and Continuous Delivery Foundation), we are happy to offer swag to active contributors! 50 most-active contributors will get an exclusive "Jenkins Is The Way" T-shirt and stickers Active contributors will get Jenkins stickers and socks We are working on special prizes for top contributors, to be announced later Acknowledgements We thank all contributors who participate in this event as committers! We especially thank all reviewers, organizers and those who participated in the initial program reviews and provided invaluable feedback. In particular, we thank User Experience, Documentation and Advocacy and Outreach SIG members who heavily contributed to this event. We also thank sponsors of the event who make the swag and prizes possible: CloudBees, Inc. and Continuous Delivery Foundation (CDF). In addition to swag, CloudBees donates working time for event hosts and reviewers. CDF also sponsors our online meetup platform which we will be using for the event. .

We would like to announce the availability of official Windows agent images for Docker. These images allow provisioning Jenkins agents with Windows OS on Docker and Kubernetes. New images All official Docker images for agents now provide nanoserver-1809 and windowsservercore-1809 tags which include Windows images and, at the moment, Java 8 (these are like the latest tag). We also provide tags with explicit Java selection, e.g. jdk8-windowsservercore-1809 or jdk11-nanoserver-1809. Version tags are also available, e.g. jenkins/agent:4.3-4-jdk8-nanoserver-1809. jenkins/agent is a basic agent which bundles the agent.jar for agent ⇐ ⇒ controller communication. This is most useful as a base image for other images. Windows images are available starting from version 4.3-4 jenkins/inbound-agent is an agent that is based on the jenkins/agent image above. It provides a wrapper script written in PowerShell to help specify the parameters to agent.jar. Windows images are available starting from version 4.3-4 jenkins/ssh-agent is an image which has OpenSSH installed and should be used with the SSH Build Agents Plugin. Windows images are available starting from version 2.1.0 Using Windows Docker images To use the new images, you will need a proper Docker or Kubernetes environment which supports running Windows containers. For Windows desktop users, the easiest way is to use Docker for Windows. Windows support in Kubernetes is documented here. jenkins/agent The jenkins/agent image is a simple agent with the JDK and the agent.jar (Jenkins Remoting library). There are two main use cases for this image: As a base image for other Docker images (e.g., FROM jenkins/agent:jdk8-nanoserver-1809 in your Dockerfile). The jenkins/inbound-agent is based on this image. This image may also be used to launch an agent using the Launch method of Launch agent via execution of command on the master. This allows the controller to launch the agent inside the docker container automatically. To run the agent for the second use case, you would specify the following command on the Jenkins controller after setting Remote root directory to C:\Users\jenkins\agent : docker run -i --rm --name agent --init jenkins/agent:jdk8-windowsservercore-1809 java -jar C:/ProgramData/Jenkins/agent.jar jenkins/inbound-agent The inbound-agent Docker image tries to provide a higher level interaction with the agent.jar executable. It provides a PowerShell wrapper script around agent.jar and it is specified as the entrypoint so that you just need to pass in some command line arguments to run the agent. A pull request has been opened which documents these command line parameters and environment variables. Example: docker run jenkins/inbound-agent:windowsservercore-1809 ` -Url http://jenkins-server:port ` -WorkDir=C:/Users/jenkins/Agent ` -Secret ` -Name Example using environment variables: docker run -e "JENKINS_URL=http://jenkins-server:port" -e "JENKINS_AGENT_NAME=AGENTNAME" ` jenkins/inbound-agent:windowsservercore-1809 ` -WorkDir=C:/Users/jenkins/Agent ` -Secret ` -Name The -Url, -Name and -Secret parameters are required, but can be specified as either command line parameters or environment variables. jenkins/ssh-agent As mentioned above the jenkins/ssh-agent docker image is based on SSH communication with the controller, rather than the remoting TCP or WebSocket protocols. The image sets up a jenkins user and the OpenSSH server so that the controller can connect to the agent via SSH. The image expects an SSH public key as a parameter and puts that key into the authorized_keys file for the jenkins user. The private key should be specified in the agent configuration on the controller to allow the controller to connect. Example: docker run jenkins/ssh-agent:jdk8-windowsservercore-1809 "" You can also pass the public key as an environment variable when using docker run. Example: docker run -e "JENKINS_AGENT_SSH_PUBKEY=" jenkins/ssh-agent:jdk8-windowsservercore-1809 You will then be able to connect this agent using the SSH Build Agents Plugin as "jenkins" with the matching private key. What’s next? We are considering providing versions based on Windows Server 2019 build 1909 so that Jenkins users can run these images on GKE clusters (see this issue). We are also looking into providing multiarch manifests which would allow Windows images to be part of the latest tag. There is also an open pull-request to create a Windows based Docker image for a Jenkins controller. There hasn’t been a lot of requests for this, but to make the offerings complete for Windows users, the pull request was created. For plans unrelated to Windows, please see the Docker images for agents: New names and What’s next blogpost.

We would like to announce the renaming of the official Docker images for Jenkins agents. It does not have any immediate impact on Jenkins users, but they are expected to gradually upgrade their instances. This article provides information about the new official names, upgrade procedure, and the support policy for the old images. We will also talk about what’s next for the Docker packaging in Jenkins. New image names jenkins/agent is the new name of the old jenkins/slave image, starting from 4.3-2 jenkins/inbound-agent is the new name of the jenkins/jnlp-slave image, starting from 4.3-2 jenkins/ssh-agent is the new name of the old jenkins/ssh-slave image, starting from 2.0.0 See the upgrade guidelines below. Why? The "slave" term is widely considered inappropriate in open source communities. It has been officially deprecated in Jenkins 2.0 in 2016, but there are remaining usages in some Jenkins components. The jira:JENKINS-42816[Slave to Agent renaming leftovers] EPIC tracks cleanup of such usages. Official Docker agent images were a glaring case, it was not easy to fix that with the previous versions of the image release Pipelines on DockerHub. It is great to have the image naming issue finally fixed by this update. Another notable change is replacing the JNLP agent term with inbound agent. Historically "JNLP" has been used as a name of Remoting protocols. JNLP stands for Java Network Launch Protocol which is a part of the Java Web Start. Jenkins supports Java Web Start mode for agents when running agents on Java 1.8, but our networking protocols are based on TCP and have nothing to do with Java Network Launch Protocol. This name has been very confusing since the beginning and became worse with the introduction of WebSocket support in Jenkins 2.217 (jep:222[]). Docker agent images support WebSockets, so we decided to change the image name to jenkins/inbound-agent so that it prevents further confusion. Inbound agent term refers to agent protocols in which the agent initiates the connection to the Jenkins controller through different protocols. Thanks a lot to Alex Earl and krufab for the repository restructuring groundwork which made the renaming possible! Also thanks to Tim Jacomb, Marky Jackson, Mark Waite, Ivan Fernandez Calvo and other contributors for their reviews and testing. Upgrading and Compatibility Notes Good news, there are no breaking changes caused by this renaming. All images have been already modified to use the new terminology internally. If you use the recent versions of the previous images, you can just replace the old names with the new ones. These names may be referenced in your Dockerfiles, scripts, and Jenkins configurations. We will keep updating the old images on DockerHub for at least 3 months (until August 05, 2020). There will be no new configurations and platforms added to the old images, but all existing ones will remain available (Debian for Java 1.8 and 11, Alpine for Java 1.8, etc.). After August 05, 2020, the old images will no longer receive updates, but previous versions will remain available to users on DockerHub. What’s next? We will continue renaming of the Docker images in Jenkins components which reference old image names. There is also a set of convenience Docker images which include build tools like Maven or Gradle which will be renamed later. The jenkins/ssh-agent image might be renamed again in the future as well; see the ongoing discussion in this developer mailing list thread. If you are rather interested in new features in Jenkins Docker packaging, stay tuned for future announcements! There are multiple ongoing initiatives which you can find on the public Jenkins roadmap (in the draft stage, see jep:14[]). Some stories: General availability of Windows images. Support for more platforms (AArch64, IBM s390x, PowerPC). Switching to AdoptOpenJDK. Introducing multi-platform Docker images. If you are interested in any of these projects and would like to contribute, please reach out to the Platform Special Interest Group which coordinates initiatives related to Jenkins in Docker. Regarding the agent terminology cleanup outside Docker images, we will keep working on this project in the Advocacy & Outreach SIG. If you see the usage of the obsolete "slave" term anywhere in the Jenkins organization (Web UI, documentation, etc.), please feel free to submit a pull request or to report an issue in the jira:JENKINS-42816[Slave to Agent renaming leftovers] EPIC. There are "just" 3000 occurences left in the jenkinsci GitHub organization, but we will get there. Any contributions will be appreciated!

One of the things we loved about going to developer conferences was meeting Jenkins users — newbies and old-timers alike — who are excited to talk about their projects and share tips on how to move forward using Jenkins. Since the coronavirus pandemic, we’re learning to rely more on new ways to gather, and it’s happening via Jenkins online meetups, GitHub collaborations, and Twitter threads, to name a few. It’s a significant change. But what hasn’t changed is the need to share stories about the things users have built, the solutions they’ve developed, and the excellent results they’re getting from some really innovative Jenkins implementations. Then we wondered, why isn’t anyone collecting these user stories and sharing them with the Jenkins community. Introducing Jenkins is the Way So we took the first step to record and archive all the great stuff everyone in our community is building with Jenkins. This way, Jenkins users old and new can come to an archive and search for Jenkins solutions for inspiration. We foresee a vast library of solutions from all around the world, solving a wide array of challenges in every industry imaginable. We decided to call this archive " Jenkins Is The Way" and host it at https://JenkinsIsTheWay.io. To aggregate all these stories, we built a simple online questionnaire so that Jenkins users can submit their own experience using this leading open source automation server. With so many plugins to support building, deploying, and automating your projects, we expect to see a vast collection of stories. We’ve already received a handful, including stories that illustrate how Jenkins Is The Way : to code your own release pipelines to cast magic of continuous delivery to understand and simplify your software lifecycle to accelerate automation in the cloud to facilitate day-to-day work Add your story. Show your Jenkins pride. Get our T-shirt Be an inspiration to the Jenkins community by sharing your Jenkins story. Just go to this link and fill out the form. We’ll ask you about your project’s goals, the technical challenges you overcame with Jenkins, and the solutions you created. It should take no more than 20-30 minutes to complete. We’ll clean it up for clarity and publish it on https://JenkinsIsTheWay.io. Once it’s part of our archive, we’ll send you our new 2020 Jenkins Is the Way t-shirt. And since the more, the merrier, please share this blog post with peers and colleagues. We want to hear everyone’s stories about the clever ways Jenkins is used to automate all that we need to do. Thanks and Acknowledgement Special thanks to abConsulting for creating and managing the https://JenkinsIsTheWay.io site and for reviewing, editing, and publishing the submitted stories. Thanks to the Jenkins Advocacy and Outreach SIG for their reviews and feedback. Thanks also to CloudBees for sponsoring the " Jenkins is the Way" program.

This blogpost was updated to reflect the general availability of the feature after the release of GitHub Branch Source 2.7.1 on April 26th, 2020. I’m excited to announce support for authenticating as a GitHub app in Jenkins. This has been a long awaited feature by many users. It has been released in GitHub Branch Source 2.7.1 which is now available in the Jenkins update centers. 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 2.7.1 or above. Configuring the GitHub Organization Folder Follow the GitHub App Authentication setup guide. These instructions are also linked from the plugin’s README on GitHub. 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_ACCESS_TOKEN')]) { sh ''' curl -H "Content-Type: application/json" \ -H "Accept: application/vnd.github.antiope-preview+json" \ -H "authorization: Bearer ${GITHUB_ACCESS_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/ / /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.

Azure Key Vault is a product for securely managing keys, secrets and certificates. I’m happy to announce two new features in the Azure Key Vault plugin: a credential provider to tightly link Jenkins and Azure Key Vault. huge thanks to Jie Shen for contributing this integration with the configuration-as-code plugin. These changes were released in v1.8 but make sure to run the latest version of the plugin, there has been some fixes since then. Some advantages of using the credential provider rather than your own scripts: your Jenkins jobs consume the credentials with no knowledge of Azure Key Vault, so they stay vendor-independent. the provider integrates with the ecosystem of existing Jenkins credential consumers, such as the Slack Notifications plugin. credential usage is recorded in the central Jenkins credentials tracking log. Jenkins can use multiple credentials providers concurrently, so you can incrementally migrate credentials to Azure Key Vault while consuming other credentials from your existing providers. Note: Currently only secret text credentials are supported via the credential provider, you can use the configuration-as-code integration to load the secret from Azure Key Vault into the System Credential Provider to work around this limitation. Getting started Install the Azure Key Vault plugin Then you will need to configure the plugin. Azure authentication There’s two types of authentication you can use 'Microsoft Azure Service Principal' or 'Managed Identities for Azure Resources' The easiest one to set this up quickly with is the 'Microsoft Azure Service Principal', $ az ad sp create-for-rbac --name http://service-principal-name Creating a role assignment under the scope of "/subscriptions/ff251390-d7c3-4d2f-8352-f9c6f0cc8f3b" Retrying role assignment creation: 1/36 Retrying role assignment creation: 2/36 { "appId": "021b5050-9177-4268-a300-7880f2beede3", "displayName": "service-principal-name", "name": "http://service-principal-name", "password": "d9d0d1ba-d16f-4e85-9b48-81ea45a46448", "tenant": "7e593e3e-9a1e-4c3d-a26a-b5f71de28463" } If this doesn’t work then take a look at the Microsoft documentation for creating a service principal. Note: for production 'Managed Identities for Azure Resources' is more secure as there’s no password involved and you don’t need to worry about the service principal’s password or certificate expiring. Vault setup You need to create a vault and give your service principal access to it: RESOURCE_GROUP_NAME=my-resource-group az group create --location uksouth --name $RESOURCE_GROUP_NAME VAULT=my-vault # you will need a unique name for the vault az keyvault create --resource-group $RESOURCE_GROUP_NAME --name $VAULT az keyvault set-policy --resource-group $RESOURCE_GROUP_NAME --name $VAULT \ --secret-permissions get list --spn http://service-principal-name Jenkins credential The next step is to configure the credential in Jenkins: click 'Credentials' click 'System' (it’ll appear below the Credentials link in the side bar) click 'Global credentials (unrestricted)' click 'Add Credentials' select 'Microsoft Azure Service Principal' fill out the form from the credential created above, appId is 'Client ID', password is 'Client Secret' click 'Verify Service Principal', you should see 'Successfully verified the Microsoft Azure Service Principal'. click 'Save' Jenkins Azure Key Vault plugin configuration You now have a credential you can use to interact with Azure resources from Jenkins, now you need to configure the plugin: go back to the Jenkins home page click 'Manage Jenkins' click 'Configure System' search for 'Azure Key Vault Plugin' enter your vault url and select your credential click 'Save' Store a secret in Azure Key Vault For the step after this you will need a secret, so let’s create one now: $ az keyvault secret set --vault-name $YOUR_VAULT --name secret-key --value my-super-secret Create a pipeline Install the Pipeline plugin if you don’t already have it. From the Jenkins home page, click 'New item', and then: enter a name, i.e. 'key-vault-test' click on 'Pipeline' add the following to the pipeline definition: // Declarative // pipeline { agent any environment { SECRET_KEY = credentials('secret-key') } stages { stage('Foo') { steps { echo SECRET_KEY echo SECRET_KEY.substring(0, SECRET_KEY.size() - 1) // shows the right secret was loaded, don't do this for real secrets unless you're debugging } } } } // Scripted // withCredentials([string(credentialsId: 'secret-key', variable: 'SECRET_KEY')]) { echo SECRET_KEY echo SECRET_KEY.substring(0, SECRET_KEY.size() - 1) // shows the right secret was loaded, don't do this for real secrets unless you're debugging } You have now successfully retrieved a credential from Azure Key Vault using native Jenkins credentials integration. configuration-as-code integration 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 easy without being a Jenkins expert. For many secrets the credential provider is enough, but when integrating with other plugins you will likely need more than string credentials. You can use the configuration-as-code plugin (aka JCasC) to allow integrating with other credential types. configure authentication As the JCasC plugin runs during initial startup the Azure Key Vault credential provider needs to be configured before JCasC runs during startup. The easiest way to do that is via environment variables set before Jenkins starts up: export AZURE_KEYVAULT_URL=https://my.vault.azure.net export AZURE_KEYVAULT_SP_CLIENT_ID=... export AZURE_KEYVAULT_SP_CLIENT_SECRET=... export AZURE_KEYVAULT_SP_SUBSCRIPTION_ID=... export AZURE_KEYVAULT_SP_SUBSCRIPTION_ID=... See the azure-keyvault documentation for other authentication options. You will now be able to refer to Azure Key Vault secret IDs in your jenkins.yaml file: credentials: system: domainCredentials: - credentials: - usernamePassword: description: "GitHub" id: "jenkins-github" password: "${jenkins-github-apikey}" scope: GLOBAL username: "jenkinsadmin" Thanks for reading, send feedback on twitter using the tweet button in the top right, any issues or feature requests use GitHub issues.