Recent Blog Posts

Congratulations to all Google Summer of Code (GSoC) 2021 students! On behalf of the Jenkins org team, we would like to thank all participants: students, mentors, applicants, and dozens of other contributors who participated in GSoC this year. In 2021, the Jenkins project participated in GSoC as part of the Continuous Delivery Foundation’s GSoC mentor organisation. Within the CDF GSoC mentor organisation, we had six students working on projects: five projects focused on Jenkins and one project focused on Spinnaker. In GSoC, we focus on projects that solve problems important to end users and community members. This year’s GSoC projects delivered highly anticipated new features for Jenkins and Spinnaker. Google Summer of Code has been a successful and positive experience for students due to the active participation of the Jenkins community and the wider Continuous Delivery Foundation community. 🎉 All of the CDF GSoC students have successfully completed their projects! 🎉 This is the second year in a row that all Jenkins GSoC students have reached the final evaluation and successfully passed! This has been an extremely challenging year, and the amount of work and dedication that the students and their mentoring teams have put into GSoC has been phenomenal. Jenkins, Spinnaker, and the CDF are incredibly grateful to everyone who has contributed to GSoC 2021! ☀️ GSoC Students and their Projects Please see the individual project pages for more details on the projects and work undertaken. You can view student presentations during mid-term demos and final demos and students have written numerous blog posts about their work. Shruti Chaturvedi - CloudEvents Plugin for Jenkins Shruti is an undergrad student of Computer Science at Kalamazoo College. She is developing a CloudEvents integration for Jenkins, allowing other CloudEvents-compliant CI/CD tools to communicate easily. Shruti is also the Founding Engineer of a California-based startup, MeetKlara, where she is building serverless solutions and advocating for developing CI/CD pipelines using open-source tools. Affiliation: Kalamazoo College and Jenkins project GitHub: ShrutiC-git LinkedIn: Shruti Chaturvedi CloudEvents Plugin for Jenkins Project page Completed project blog post: Jenkins Interoperability with CloudEvents Mid-term blog: CloudEvents Plugin for Jenkins: Interoperability between Jenkins and other CI/CD Tools Final demo Mid-term demo Harshit Chopra - Git credentials binding for sh, bat, and powershell Harshit Chopra is a recent graduate and is currently working on a Jenkins project which brings the authentication support for cli git commands in a pipeline job and freestyle project. Affiliation: Punjab University & Jenkins Project GitHub: link: arpoch LinkedIn: Harshit Chopra Website Git credentials binding for sh, bat, and powershell Project page Mid-term blog: Git Credentials Binding for sh, bat, powershell Final demo Mid-term demo Akihiro Kiuchi - Jenkins Remoting Monitoring Akihiro is a student in the Department of information and communication engineering at the University of Tokyo. He is improving the monitoring experience of Jenkins Remoting during Google Summer of Code 2021. Affiliation: The University of Tokyo and Jenkins project GitHub: Aki-7 Jenkins Remoting Monitoring with OpenTelemetry Project page Mid-term blog: Remoting Monitoring with OpenTelemetry Final demo Mid-term demo Daniel Ko - try.spinnaker.io Daniel is studying computer science at the University of Wisconsin - Madison. He is developing a public Spinnaker sandbox environment for Google Summer of Code 2021. Affiliation: University of Wisconsin - Madison and Spinnaker project GitHub: ko28 LinkedIn: Daniel Ko try.spinnaker.io: Explore Spinnaker in a Sandbox Environment! Project page Completed project blog post: Interview with Daniel Ko — Google Summer of Code 2021 Final demo Mid-term demo Pulkit Sharma - Security Validator for Jenkins Kubernetes Operator Pulkit is a student at Indian Institute of Technology,BHU,Varanasi. He is working on a GSoC Project under Jenkins where he aims to add a security validator to the Jenkins Kubernetes Operator. Affiliation: Indian Institute of Technology, BHU and Jenkins Project. GitHub: sharmapulkit04 Security Validator for Jenkins Kubernetes Operator Project page Completed project blog post: Security Validator for Jenkins Operator for Kubernetes Final demo Mid-term demo Aditya Srivastava - Conventional Commits Plugin for Jenkins Aditya is a curiosity driven individual striving to find ingenious solutions to real-world problems. He is an open-source enthusiast and a lifelong learner. Aditya is also the Co-Founder and Maintainer of an Open Source Organization - Auto-DL, where he’s leading the development of a Deep Learning Platform as a Service application. Affiliation: V.E.S.I.T & Jenkins project GitHub: ADI10HERO LinkedIn: Aditya S. Conventional Commits Plugin for Jenkins Project page Completed project blog post: Work report for the Conventional Commits Plugin for Jenkins Mid-term blog: Introducing the Conventional Commits Plugin for Jenkins Final demo Mid-term demo Upcoming Events, September 28-30: DevOps World! This year CloudBees, one of the Jenkins corporate sponsors, has invited all students to participate in the DevOps World virtual conference on September 28-30. GSoC students will present lighting talks about their projects, attended other conference talks, and join the Continuous Delivery Foundation booth which represents CDF projects at the conference. We look forward to GSoC students' lightning talks during DevOps World! Swag All Google Summer of Code students and mentors receive swag from Google. In addition, this year, CloudBees has sponsored swag for the most active GSoC participants: all students, mentors, and many other contributors who participated and helped the projects to succeed. This is the forth year when the Jenkins organization sends extra GSoC swag. In the previous years swag logistics was one of the more challenging tasks for org admins during GSoC, and we highly appreciate that the Continuous Delivery Foundation will handle sending out the additional swag. Thanks you Google Open Source, Continuous Delivery Foundation (CDF) and CloudBees!

This blog post is part 2 of the Introducing the Conventional Commits Plugin blog. The goal of this blog is to showcase the work done during the Google Summer of Code 2021 coding phases. Please refer the part 1 of the blog for a detailed description of the plugin. Abstract The project/plugin aims to fully automate a release process. The plugin tries to achieve this goal by automatically determining the next semantic version based on commit messages. There were 2 coding phases in the GSoC 2021. I call the first phase - "Read" and the 2nd phase - "Write", let’s see why. Phase 1: Read In this phase, the "read" aspect of the plugin was enhanced. The plugin supported multiple project types (Maven, Gradle, NPM, Helm, Python, Make) and was able to read current version information from the configuration files of the supported project types. Deliverables Support multiline comments Support reading the current version from a maven pom.xml Support reading the current version from a build.gradle Support reading the current version from a Makefile Support reading the current version from a package.json Support reading the current version from a helm Chart.yaml Resources List of related issues Phase 1 Demo and Presentation: Phase 2: Write In this phase, some work was done in extending the "write" aspect of the plugin. A provision (optional parameter) to write back the calculated next semantic version to the configuration files of projects was added to the plugin. Along with that, the plugin now can append "Pre-Release" and "Build Metadata" information to the calculated semantic version. Deliverables Add prerelease information to the calculated/new version Add build metadata to the calculated/new version Write next version in pom.xml Write next version in package.json Handle version mismatch between config file and latest tag Resources Link to related Issues Using optional parameters in the Conventional Commits Plugin Phase 2 Presentation Next Steps Write back version for Python project. Write back version for Gradle project. Handle remote workspaces Feedback We would love to hear your feedback & suggestions for the plugin. Please reach out on the plugin’s GitHub repository, the Gitter channel or start a discussion on community.jenkins.io.

Abstract This project implemented two new credential bindings to perform authenticated operations using command line git in Jenkins pipeline and freestyle jobs. The two credential bindings are gitSshPrivateKey and gitUsernamePassword. Implementation Type Feature Location The gitUsernamePassword binding is implemented in Jenkins git plugin v4.8.0. The gitSshPrivateKey binding is implemented in a pull request to the Jenkins git plugin Dependencies Credentials Binding Plugin - It is used to bind Git specific environment variables with shell scripts/commands which perform git authentication on behalf of the user, without their interaction with the command-line. Bouncy Castle API Plugin - Provides an API to do common tasks like PEM/PKCS#8 Encoding/Decoding and ensuring its stability among Bouncy Castle API versions. SSH Server Plugin - Provides an API to perform tasks like OpenSSH private key encoding and decoding. Phase 1: Git Username Password Binding (gitUsernamePassword) Deliverables Support git authentication over the HTTP protocol Use the GIT_ASKPASS environment variable to provide user credentials to command line git Support different OS environments : CentOS 7, CentOS 8, Debian 9, Debian 10, FreeBSD 12, OpenBSD 6.9, openSUSE 15.2, Ubuntu 18.04, Ubuntu 20.04, Ubuntu 21.04, and Windows 10. Processors : amd64, arm32, arm64, and s390x. Authentication support for command line git only, not JGit or JGit Apache. Check for specific git versions Setting git specific environment variables based on OS type Automated test coverage more than 90% Resources Pull Requests Add Git Credentials binding for Username and Password Check the least command line git version required Git username password binding doc update in git-plugin gitUsernamePassword binding explanation Webinar slides Git username password binding released blog post Phase 1 demo and presentation: Phase 2: Git SSH Private Key Binding (gitSshPrivateKey) Deliverables To support git authentication over the SSH protocol Supports: Private Key Formats OpenSSH PEM PKCS#8 Encryption algorithms RSA DSA ECDSA ED25519 OS environments : CentOS 7, CentOS 8, Debian 9, Debian 10, FreeBSD 12, OpenBSD 6.9, openSUSE 15.3, Ubuntu 18.04, Ubuntu 20.04, Ubuntu 21.04, and Windows 10. Processors : amd64, arm32, arm64, and s390x. Authentication support for command line git only, not JGit or JGit Apache. Use git specific environment variables depending upon the minimum git version GIT_SSH_COMMAND - If the version is greater than 2.3, provides ssh command including the necessary options. SSH_ASKPASS - If the version is less than 2.3, an executable script is attached to the variable. Setting variables based on the OS type Resources Pull Requests Add Git Credentials binding for SSH Private Key Last GSOC-2021 noted commit Scope change of getSSHExecutable method gitSshPrivateKey binding explanation Webinar Slides Final phase demo and presentation Achievements The git credential bindings which are available through the git plugin automate the git authentication process for a user effortlessly The gitUsernamePassword and gitSshPrivateKey binding provides git authentication support for Pipeline and Freestyle Project users in various OS environments on different processors The gitUsernamePassword binding has been released and is readily available from git plugin v4.8.0 and above The gitSshPrivateKey binding provides support for OpenSSH format which is default for OpenSSH v7.8 and above Future Work SSH private key binding pull request merge and release Unexpected complications from Jenkins class loader required extra effort and investigation, including an experiment shading a dependency into the git plugin We intentionally chose to avoid the complication and risk of shading the dependency If the SSH library use requires shading, then we may need to use maven modules in the git plugin

The What, Why and How of Interoperability With workloads and teams becoming more diverse and complex, there is an increasing need to automate various tasks in the CI/CD ecosystem of an application as a way to decrease complexity that can come with CI/CD. A more diverse team working across different aspects of the application requires a diverse suite of CI/CD tools too, to test and deliver to a wide range of users. More often than not, we need these tools to work together and exchange data to form an effective CI/CD pipeline. However, chaining multiple services together can very easily increase complexity. How? Each of these services use a different "language" to communicate and represent the entity(an event) which occured inside that service. In order for another service to understand this "language", the service might need to develop customized clients and agents which specialize in understanding, traversing and taking-actions based on what was transmitted to it by the first service. One can think of it as a translator who specializes in a language called ABC, and each service who wants to communicate with the service who uses ABC will have to employ this translator, or perhaps get another trained translator. And there is no guarantee that this translator will also help communicate with other services speaking a completely different language. We can see how easily that can grow in cost and maintenance. A preferred way is to have a common language each of these services use and understand as a way to communicate amongst each other. This way, an event which is emitted using this common language will be available to any of the interested receiver without that receiver needing a special agent. This way of communication which uses a common/standard language also creates a way for agnostic communication where the sender or the receiver are sending and receiving data without creating a tight coupling between the two. CloudEvents specification is enabling that loosely-coupled, event-driven communication between services by enforcing a common language which defines how an event should be emitted and transferred between systems. CloudEvents and Jenkins A specification for describing event data in a common way Consistency Consistent across tools and services. Accessibility Common event format means common libraries, tooling, and infrastructure for delivering event data across environments can be used to develop with CloudEvents. Portability Easily port event-data across tools, truly leveraging event-driven architecture. The CloudEvents plugin for Jenkins is developed as an effort to make interoperability between Jenkins and CI/CD tools much easier. The CloudEvents plugin for Jenkins is a GSoC project, and with the help from an amazing team of mentors, this project is aimed at enhancing event-driven interoperability between cloud-native CI/CD tools, making it easier for developers to include Jenkins in their CI/CD pipelines. With this plugin, Jenkins can send and receive CloudEvents-compliant events to and from a wide variety of CI/CD tools using CloudEvents as their event format. This plugin makes chaining Jenkins with multiple tools like Tekton, Keptn, Knative and more, very easy. GSoC Phase 1 - CloudEvents Plugin Using CloudEvents plugin for Jenkins This plugin allows Jenkins to be configured as a source and sink, which can emit and consume CloudEvents from a range of tools simultaneously. Jenkins as a Source Configuring Jenkins as a Source enables Jenkins to send CloudEvents to a CloudEvents sink. For Phase-I of this project, there is support for HTTP Sinks, however CloudEvents supports various protocol bindings. Moving forward, there will also be support for other protocol bindings supported by CloudEvents. To use Jenkins as a Source, the following configuration is needed: Click on Manage Jenkins in the Root-Actions menu on the left. Inside the Manage Jenkins UI, search for Configure System under System Configuration. In the Configure System UI, scroll down to the CloudEvents plugin section, and this is where all the plugin configuration will be present. Here, you will have to enter the following information: Sink Type (For now, HTTP Protocol Binding for CloudEvent and HTTP Sink is supported.) Sink URL (URL of the Sink where you want the cloudevents sent.) Events you want sent to the CloudEvents sink URL. Step 1: Manage Jenkins Step 2: Configure System Step 3: Configure CloudEvents Sink With Jenkins as a Source configured, Jenkins will send a POST request to the configured sink right as the selected event occurs inside Jenkins. Each event has a different payload specific to the type of the event emitted. Event Types, Payload and Metadata CloudEvents emitted by Jenkins follow the Binary-structure supported by CloudEvents, where the CloudEvents metadata is present inside the header, and the event-data is serialized as JSON, and present under request-body. This is the HTTP Protocol Binding for CloudEvents. Each protocol binding for CloudEvents follows a definition specific to the binding protocol. For now, the following Jenkins events are supported in the CloudEvents Plugin-Jenkins as a Source: Queue Events Queue Entered Waiting Queue Left Build Events Job Started Job Completed Job Finalized Job Failed Job Events Job Created Job Updated Node Events Node Online Node Offline Following is a table of the queue-entered waiting cloudevents metadata: Event Metadata Headers Key Event Metadata Headers Value ce-specversion 1.0 ce-type org.jenkinsci.queue.entered_waiting ce-source job/test ce-id 123-456-789 All of these fields will be present inside the HTTP-request headers since the CloudEvents format used here is the Binary structure. Here’s also an example of event payload for the queue-entered event: { "ciUrl": "http://3.101.116.80/", "displayName": "test2", "entryTime": 1626611053609, "exitTime": null, "startedBy": "shruti chaturvedi", "jenkinsQueueId": 25, "status": "ENTERED_WAITING", "duration": 0, "queueCauses": [ { "reasonForWaiting": "In the quiet period. Expires in 0 ms", "type": "entered_waiting" } ] } Try the Plugin The plugin will soon be releasing as the CloudEvents Plugin under https://plugins.jenkins.io/!! Here’s the GitHub Repo of the Plugin: CloudEvents Plugin GitHub Repo Demo Here is a video of the CloudEvents plugin with SockEye demoed at CDF GSoC Midterm Demos. SockEye is an open-source tool which is designed as a way to visulaize cloudevents which are sent from a sink. In this demo, we will take a look at how Jenkins installed in a multi-node K8s environment work with the CloudEvents plugin as a Source, sending events over HTTP to the SockEye sink. Next Steps Jenkins as a Sink to allow Jenkins to trigger various actions as cloudevents are received from other tools. Enabling filtering on CloudEvents metadata to only act upon a certain kind of events recieved. Support for other protocol bindings in CloudEvents. Feedback We would absolutely love to hear your suggestions and feedback. This will help us understand the various use-cases for the plugin, and iterate to support a variety of bindings and formats. Feel free to log an issue at the CloudEvents Plugin GitHub repository. We are on CDF slack under gsoc-2021-jenkins-cloudevents-plugin. You can also start a discussion on community.jenkins.io. I also love emails! Drop me one on: shrutichaturvedi16.sc@gmail.com

Goal The goal of this project: collect telemetry data(metrics, traces, logs) of remoting module with OpenTelemetry. send the telemetry data to OpenTelemetry Protocol endpoint Which OpenTelemetry endpoint to use and how to visualize the data are up to users. OpenTelemetry An observability framework for cloud-native software OpenTelemetry is a collection of tools, APIs, and SDKs. You can use it to instrument, generate, collect, and export telemetry data(metrics, logs, and traces) for analysis in order to understand your software’s performance and behavior. Phase 1 summary User survey Our team conducted a user survey to understand the pain point regarding Jenkins remoting. Fig 1. What agent type/plugins do you use? Fig 1 shows what types of agent users use, and 17 unique respondents out of 28 use docker for agent. So I’m planning to publish a docker image to demonstrate how we can build Docker image with our monitoring feature. This survey and investigation of JIRA tickets of past two years also tell me five common causes of agent unavailability. Configuration mistakes Jenkins agent settings, e.g. misuse of "tunnel connection through" option. Platform settings, e.g. invalid port setting of Kubernetes' helm template. Network settings, e.g. Load balancer misconfiguration. Uncontrolled shutdown of nodes for downscaling. Timeout during provisioning a new node. Firewall, antivirus software or other network component kill the connection Lack of hardware resources, e.g. memory, temp space, etc…​ We also heard valuable user voice in the survey. What areas would you like to see better in Jenkins monitoring? I have created a bunch of adhoc monitoring jobs to check on the agent’s health and send e-mail. Would be nice to have this consolidated. Having archive of nodes with the access to their logs/events would have been nice. I hope that implementing these feature with OpenTelemetry, which is expected to become the industry standard for observability, will bring great monitoring experience to Jenkins community. Proof of Concept How to deliver the monitoring program to agents 1. Sending monitoring program to the agent over remoting In my first implementation, I prepared a Jenkins plugin and send the monitoring program from Jenkins controller. However, this approach have following disadvantages. We cannot collect telemetry data before the initial connection. We are likely to encounter a problem while provisioning a new node, so it’s important to observe agents' telemetry data from the beginning. Some agent restarters (e.g. UnixSlaveRestarter) restart agent completely when reconnecting. It means that the agent lost monitoring program every time the connection closed, and we cannot collect telemetry data after the connection is lost before a new connection is established. So we decided to take the next approach. 2. Install monitoring engine when provisioning a new agent In this approach, user will download the monitoring program called monitoring engine, which is a JAR file, and place it in the agent node when provisioning. How to instrument remoting to produce remoting trace Add instrumentation extension point to remoting Pull Request: https://github.com/jenkinsci/remoting/pull/471 This approach makes the agent launch command more complicated, and we have to overcome this problem. Current State Metrics We currently support the following metrics and planning to support more. metrics unit label key description system.cpu.load 1 System CPU load. See com.sun.management.OperatingSystemMXBean.getSystemCpuLoad system.cpu.load.average.1m System CPU load average 1 minute See java.lang.management.OperatingSystemMXBean.getSystemLoadAverage system.memory.usage bytes state used, free see com.sun.management.OperatingSystemMXBean.getTotalPhysicalMemorySize and com.sun.management.OperatingSystemMXBean.getFreePhysicalMemorySize system.memory.utilization 1 System memory utilization, see com.sun.management.OperatingSystemMXBean.getTotalPhysicalMemorySize and com.sun.management.OperatingSystemMXBean.getFreePhysicalMemorySize. Report 0% if no physical memory is discovered by the JVM. system.paging.usage bytes state used, free see com.sun.management.OperatingSystemMXBean.getFreeSwapSpaceSize and com.sun.management.OperatingSystemMXBean.getTotalSwapSpaceSize. system.paging.utilization 1 see com.sun.management.OperatingSystemMXBean.getFreeSwapSpaceSize and com.sun.management.OperatingSystemMXBean.getTotalSwapSpaceSize. Report 0% if no swap memory is discovered by the JVM. process.cpu.load % Process CPU load. See com.sun.management.OperatingSystemMXBean.getProcessCpuLoad. process.cpu.time ns Process CPU time. See com.sun.management.OperatingSystemMXBean.getProcessCpuTime. runtime.jvm.memory.area bytes type used, committed, max see MemoryUsage area heap, non_heap runtime.jvm.memory.pool bytes type used, committed, max see MemoryUsage pool PS Eden Space, G1 Old Gen…​ runtime.jvm.gc.time ms gc G1 Young Generation, G1 Old Generation, …​ see GarbageCollectorMXBean runtime.jvm.gc.count 1 gc G1 Young Generation, G1 Old Generation, …​ see GarbageCollectorMXBean Traces We tried several approaches to instrument remoting module, but good approach is not established yet. Here is a draft documentation of the spans to collect. Google Doc Logs Coming soon! Metric and span demo visualization Our team created a demo example with Docker compose and visualized the metrics and spans. Click to open in new tab Google Summer of Code Midterm Demo Our project demo starts with 8:20 Next Step Log support Alpha release!

The conventional commits plugin is a Google Summer of Code project. Special thanks to the mentors Gareth Evans, Kristin Whetstone, Olivier Vernin and Allan Burdajewicz. What are Conventional Commits According to the official website, conventonal commits are, "A specification for adding human and machine readable meaning to commit messages." Conventional commits are a lightweight convention on top of commit messages. The following table shows major structural elements offered by the conventional commits convention. Structural Element Example Chore chore: improve logging Fix fix: minor bug fix Feat feat: add a new feature Breaking Change BREAKING CHANGE: reimplement Why Conventional Commits As the CI/CD world is moving more towards complete automation and minimal human interaction, the ability to fully automate a release is desired. Conventional Commits enable the use of automated systems on top of commit messages. These systems can "truly" automate a release with almost no human interaction. The convention dovetails with semantic versioning. Let’s take an example, a maven project is currently versioned at 1.2.0. The following table shows how conventional commits would bump the version depending on the type of the commit. Commit Message Version Bump SemVer Equivalent chore: improve logging 1.2.0 → 1.2.0 No version bump fix: minor bug fix 1.2.0 → 1.2.1 Increment in the patch version feat: add a new feature 1.2.0 → 1.3.0 Increment in the minor version BREAKING CHANGE: reimplement 1.2.0 → 2.0.0 Increment in the major version The Conventional Commits Plugin The conventional commits plugin is a Jenkins plugin to programatically determine the next semantic version of a git repository using: Last tagged version Commit message log Current version of the project How it works? The plugin will read the commit messages from the latest tag or the current version of the project till the latest commit. Using this information it will determine what would be the next semantic Version for that particular project. Supported Project Types? Currently the plugin can read the current version from various configuration files of the following project types: Project Type Configuration File(s) Read Maven pom.xml Gradle build.gradle Make Makefile Python setup.py setup.cfg pyproject.toml Helm Charts.yml Node (NPM) package.json How to request a project type support? Please feel free to open an issue on the GitHub repository of the plugin. How to use the plugin Recommended way of using the plugin is to add a step in a Jenkins Pipeline Project. nextVersion() is the pipeline step to be used. For example: pipeline { agent any environment { NEXT_VERSION = nextVersion() } stages { stage('Hello') { steps { echo "next version = ${NEXT_VERSION}" } } } } Tip: The pipeline step can also be generated with the help of the Snippet Generator. Please select "nextVersion" in the Sample Step drop down and then click on "Generate Pipeline Snippet" The plugin is released on every feature using JEP-229. The plugin is available to download from the plugins site. Demo You can watch the plugin in action in a demo presented at the GSoC Midterm Presentations Next Steps Support for pre-release information. Example: 1.0.0-alpha, 1.0.0-beta, etc Support for build metadata. Example: 1.0.0-beta+exp.sha.5114f85 Optionally writing the calcuated "Next Version" into the project’s configuration file. Example: pom.xml for a maven project, setup.py for python. Feedback We would love to hear your feedback & suggestions for the plugin. Please reach out on the plugin’s GitHub repository, the Gitter channel or start a discussion on community.jenkins.io.

Congratulations to all GSoC students who have made it through the first half of the GSoC 2021 coding phase! This year, the Jenkins project has been participating in GSoC as part of the Continuous Delivery Foundation’s GSoC org. To celebrate our GSoC students and the fantastic work they have been doing, the CDF is hosting an online meetup where students will present their work. Students will be showcasing what they have learned and accomplished thus far in GSoC, demoing their work, and discussing their goals and plans for the second coding phase. The CDF Google Summer of Code Midterm Demos will be held online on July 20th, 13:00 UTC - 15:00 UTC. Sign up here: Meetup Event Speakers Akihiro Kiuchi - Jenkins Remoting Monitoring Akihiro is a student in the Department of information and communication engineering at the University of Tokyo. He is improving the monitoring experience of Jenkins Remoting during Google Summer of Code 2021. Affiliation: The University of Tokyo and Jenkins project GitHub: Aki-7 Title: Jenkins Remoting Monitoring with OpenTelemetry In this talk, he will discuss the problems in maintaining Jenkins agents and how to support Jenkins admins in troubleshooting them. As one of the solutions, he will introduce the new Remoting monitoring with OpenTelemetry plugin that collects Jenkins Remoting monitoring data and troubleshooting data using OpenTelemetry. What kind of data the plugin will collect and how we will be able to visualize them using available open-source monitoring tools will be demonstrated. Shruti Chaturvedi - CloudEvents Plugin for Jenkins Shruti is an undergrad student of Computer Science at Kalamazoo College. She is developing a CloudEvents integration for Jenkins, allowing other CloudEvents-compliant CI/CD tools to communicate easily. Shruti is also the Founding Engineer of a California-based startup, MeetKlara, where she is building serverless solutions and advocating for developing CI/CD pipelines using open-source tools. Affiliation: Kalamazoo College and Jenkins project GitHub: ShrutiC-git LinkedIn: Shruti Chaturvedi Title: CloudEvents Plugin for Jenkins: Moving Towards Interoperability In this talk, we will look at interoperability as an essential element in building workloads across several services. We will also talk about how CloudEvents solves one of the biggest challenges in achieving interoperability between systems: lack of normalization/standardization. Without any standard definition, in order to achieve interoperability, services have to develop adapters specific to a particular system. That, however, is complex because services are always changing the way data/events are emitted. CloudEvents solves this problem by defining a standard format for events, which can be emitted/consumed agnostically, thereby achieving indirect interoperability. Shruti will demonstrate the workings of CloudEvents Plugin for Jenkins; she will walk us through how Jenkins can be configured as a source and a sink, emitting and consuming CloudEvents-compliant events in a platform-independent manner. Daniel Ko - try.spinnaker.io Daniel is studying computer science at the University of Wisconsin - Madison. He is developing a public Spinnaker sandbox environment for Google Summer of Code 2021. Affiliation: University of Wisconsin - Madison and Spinnaker project GitHub: ko28 Title: try.spinnaker.io: Explore Spinnaker in a Sandbox Environment! The talk will go through a brief explanation of Spinnaker and the challenges that users face during the installation process. He will discuss the infrastructure of this project and how a public multi tenant spinnaker instance will be managed and installed. We will end with a demo of the site so far and the various features implemented, including Github authentication, K8s manifest deployment, AWS Load Balancer Controller to expose deployments, private ECR registry and the blocking of all public images, and auto resource cleanup. Aditya Srivastava - Conventional Commits Plugin for Jenkins Aditya is a curiosity driven individual striving to find ingenious solutions to real-world problems. He is an open-source enthusiast and a lifelong learner. Aditya is also the Co-Founder and Maintainer of an Open Source Organization - Auto-DL, where he’s leading the development of a Deep Learning Platform as a Service application. Affiliation: V.E.S.I.T & Jenkins project GitHub: ADI10HERO LinkedIn: Aditya S. Title: Conventional Commits Plugin for Jenkins In this talk, we’ll start with what are conventional commits and why they are needed. Then we’ll see what the jenkins plugin, "Conventional Commits" is and what goal it is trying to achieve. A demo of how the plugin can be used/integrated in the current workflow will be shown. Finally, we’ll talk about the next steps in plugin development followed by the QnA. Harshit Chopra - Git credentials binding for sh, bat, and powershell Harshit Chopra is a recent graduate and is currently working on a Jenkins project which brings the authentication support for cli git commands in a pipeline job and freestyle project. Affiliation: Punjab University & Jenkins Project GitHub: link: arpoch LinkedIn: Harshit Chopra Website Title: Git credentials binding for sh, bat, and powershell In this talk, he will give an overview of the project and will move on further explaining what problems are being faced, a bit about the workaround that are being used to tackle the problems, what makes the authentication support so important, why a feature and not a plugin in itself, accomplishments achieved and work done during the coding phase 1, will talk about the implementation of the feature, demonstration of git authentication support over HTTP protocol. Pulkit Sharma - Security Validator for Jenkins Kubernetes Operator Pulkit is a student at Indian Institute of Technology,BHU,Varanasi. He is working on a GSoC Project under Jenkins where he aims to add a security validator to the Jenkins Kubernetes Operator. Affiliation: Indian Institute of Technology, BHU and Jenkins Project. GitHub: sharmapulkit04 Title: Security Validator for Jenkins Kubernetes Operator In this talk, we will discuss why we need a security validator for the Jenkins Kubernetes Operator and how we are going to implement it via admission webhooks. We will have a look at how we are going to implement the validation webhook, the validation logic being used and what tools we are using to achieve it. Pulkit will showcase his progress and will discuss his future plans for phase 2 and beyond as well.

On behalf of the Jenkins GSoC org team, I am happy to announce that this year, for the first time, the Jenkins projects will be participating in Google Summer of Code 2021 as part of the Continuous Delivery Foundation (CDF) GSoC organization. We’re very excited to have the Jenkins project participate in GSoC as part the CDF mentoring organisation along with fellow CDF projects such as Ortelius, Screwdriver, Spinnaker, and Tekton. We believe that being part of the CDF GSoC org will create an environment for students with even more mentoring channels, potential cross-fertilization of ideas, and an even greater community of DevOps practitioners to join! What’s next? GSoC is officially announced, and please expect more students to contact projects in our Gitter channels and mailing lists. Many communications will also happen in SIG and sub-project channels. Also, please join the gsoc channel on the /">CDF Slack. We will be working hard in order to help students to find interesting projects, to explore the area, and to prepare their project proposals before the deadline on April 13th. Then we will process the applications, select projects and assign mentor teams. All information about the Jenkins GSoC is available on its sub-project page. I am a student. How do I apply? See the Information for students page for full application guidelines. We encourage interested students to reach out to the Jenkins community early and to start exploring project ideas. All project ideas have chats and mailing lists referenced on their pages. We will be also organizing office hours for students, and you can use these meetings to meet org admins and mentors and to ask questions. Also, join our Gitter channel and the mailing list to receive information about such incoming events in the project. The application period starts on March 29th, but you can prepare now! Use the time before the application period to discuss and improve your project proposals. We also recommend that you become familiar with Jenkins and start exploring your proposal areas. Project ideas include quick-start guidelines and reference newbie-friendly issues which may help with initial study. If you do not see anything interesting, you can propose your own project idea or check out ideas proposed by other CDF organizations participating in GSoC. I want to be a mentor. Is it too late? It’s not! We are looking for more project ideas and for Jenkins contributors/users who are passionate about Jenkins and want to mentor students. No hardcore experience required, mentors can study the project internals together with students and technical advisors. We are especially interested in ideas beyond the Java stack, and in ideas focusing new technologies and areas (e.g. Kubernetes, IoT, Python, Go, whatever). You can either propose a new project idea or join an existing one. See the Call for Mentors post and Information for mentors for details. If you want to propose a new project, please do so as soon as possible so that students have time to explore them and to prepare their proposals. This year mentorship does NOT require strong expertise in Jenkins development. The objective is to guide students and to get involved into the Jenkins community. GSoC org admins will help to find advisers if special expertise is required. Testimonials from former Jenkins GSoC participants ❤️ "I participated in Google Summer of Code 2020 in cooperation with the Jenkins organization and I work on a project called Windows Service Wrapper, which allows running Jenkins as a service on a Windows machine. GSoC was the most wonderful and the most valuable experience I gained during my student life. The whole journey was full of experiences and Jenkins mentors always were there for us. I experienced a huge development of my skills while I was working on the project. I had many meetings, knowledge sharing sessions, and one pair-coding session with my mentors. One of the best things that I learned is the open-source community and open source mentality. It is not only about taking, but also about giving. Today I am maintaining an open-source project which is a simple programming language for kids which allows them to code in their native language, which will help to learn coding to students in rural areas of my country. Finally, Jenkins is a wonderful family and they always were there for us in all the ups and downs. I am proud to be a part of the Jenkins community." Buddhika Chathuranga, GSoC 2020 student, Support for YAML Configuration in Windows Service Wrapper "My GSoC journey in the Jenkins community starts by a draft proposal full of comments from mentors and ends by two plugins with hundreds of installations. Along with the daily coding review, the weekly meeting and the growth of the project, I increased my skills on programming and became a much more eligible engineer. What is more, the support from the whole Jenkins community leads me to a broader career path. I learned how to maintain a project, how to communicate with users and other developers on GitHub. Most importantly, the Jenkins community teaches me the principles of the open source world and welcomes me to the open source world with all their kind help." Kezhi Xiong, GSoC 2020 students, GitHub Checks API project "I worked as a Google Summer of Code student with the Jenkins project during the summer of 2019. The project provided me with an excellent opportunity to contribute to the world’s most popular automation server, learn about building performant and reliable applications, and interact with awesome people around the globe. Jenkins' ever helpful and extremely knowledgeable community made working on my project a real treat. I even got a chance to present my project at DevOps World in Lisbon! If you’re deciding which organization to work for this year, choose the Jenkins project — you can’t have a better GSoC experience than this!" Abhyudaya Sharma, GSoC 2019 student, Role Strategy Performance Improvements "I participated in Google Summer of Code 2018 with Jenkins as a student developer. Working for Jenkins in GSoC 2018 was one of the best experiences I have ever had. During 3 months of summer, I learned a lot of new things when working on the open-source project with Jenkins. Another best thing about Jenkins is the people, I received a lot of support from my mentors and other developers from the Jenkins community when working on my project. After GSoC, I also had a chance to go to the Jenkins World Conference in San Francisco to meet and connect with my mentors and other people in the Jenkins community. Overall, GSoC with Jenkins was a great experience and I highly recommend Jenkins as a great community to kickstart your open source journey." Pham Vu Tuan, GSoC 2018 student, Remoting over Apache Kafka project Important dates for GSoC 2021 Apr 13 - deadline for student applications May 17 - accepted projects announced, teams start community bonding and coding Aug 16 - coding period ends Aug 31 - Results announced See the GSoC Timeline for more info.