Recent Blog Posts

After an amazing three months of development period in the summer of 2019 with Jenkins Project, I was a better developer, loved open source, met passionate people and had fun at work. Jenkins is not just a community, it is a family. When GSoC period was over, we received swags from Jenkins. Natasha Stopa (one of the students in GSoC 2019) was invited to attend DevOps World | Jenkins World San Francisco. It was nice to see her enjoy there. But guess what? Jenkins also invited three other students (Abhyudaya, Long and me) to DevOps World | Jenkins World Lisbon. I was super psyched when Marky Jackson (one of my project mentors) broke the news to me. The trip to Lisbon required to sort a few things like flight tickets, hotel booking, passport, visa etc. Oleg Nenashev had scheduled meetings to discuss and help us with arranging everything for our travel. Thanks to him. :) From India to Lisbon (Dec 1) Abhyudaya and I boarded our flight from Indira Gandhi Airport (New Delhi) to Lisbon on December 1, 2019 morning at 0500 hours (local time). It was a fine trip with an hour layover in Istanbul Ataturk Airport. We arrived in Lisbon at 1500 hours (local time). The weather in Lisbon was terrific. A mild cold but strong sea breeze was the starting point of me falling in love with the place. We arrived at our hotel (Novotel Lisboa) in an Uber. Oleg met us at the lobby to help us with check-in. It was great to finally meet him in person after months of knowing and working together. We had a good chat about the event, what to expect and other sightseeing areas. After a short time of refresh, Long who traveled from Berlin a day before met us at the restaurant. We had a brief chat knowing each other, had our food and went to bed. The next day was Hackfest. We hit the bed after that as we had to reach Centro de Congressos de Lisboa (CCL) where the event was organised by 0900 hours. Day 0 (Dec 2) I woke up early for a short jog in the streets. Lisbon is a city made on hills. The streets have beautiful mosaic styled pavements. It was nice to see around the city. Then Abhyudaya and me went for breakfast and reached CCL in an Uber at 0815 hours. There was a round table sitting arrangement in an auditorium. It was like a meet-and-greet event to interact with other developers (some known and some new). Everybody had to figure out their problem statements and work on it. There was milk, juice, sandwiches which gave us energy throughout the day. I took a small break to come out of the building to go to the other side of the road which was on the banks of Tagus River. From there you could have very close view underneath the Ponte 25 de Abril (looks strikingly similar to Golden Gate Bridge). You can also see The Sanctuary of Christ the King on the other side of the river (again looks similar to Christ the Redeemer in Rio, Brazil). It was great to kick off the event with Hackfest. At the end of Hackfest some of us presented our work. Later, we went to a nearby restaurant to have burgers which apparently was the best burger I ever had (could be because I hadn’t tried too many burgers before :P). We talked and interacted with people from other parts of the world for about an hour and a half then went back to our hotel rooms. Day 1 (Dec 3) The conference officially began on this day. Abyudaya and me had breakfast and took the shuttle to CCL. We collected our t-shirts and IDs. The event managing team made an app for DevOps World | Jenkins World (DWJW) Lisbon with all schedules and other informations which was incredibly convenient for all attendees. There were multiple sessions/events on different topics related to Jenkins or DevOps in general. I attended the Jenkins and Jenkins X contributor summit. Had a nice lunch and went around to explore Lisbon. I went to Padrao dos Descobrimentos and the beautiful Belem Palace. Had some Pasteis de Belem (a popular Portuguese desert). Took a tram to Praça do Comércio. It is Lisbon’s most important square. You will find lots of tourists, street bands, sea food restaurants, shops for every budget, the famous pink street and so much more. Later that evening we had a party hosted by EURODOG (European DevOps Group) at Lisboa Marriott. It was a nice party to network with developers over casual wine and beer. We later head out to a nearby Indian restaurant for Kebab and rice. Day 2 (Dec 4) The second day began with the opening keynote. Later went to the Jenkins X Introduction, Deploying K8s with Jenkins on GCP, Build top mobile games by King in that order. Also occasionally hitting the sponsors booth to have a chat and collect some swags. In the evening there was the superhero themed party, sponsored by Sonatype. It was probably the most fun event in the entire conference. The expo hall had an entirely different look with the party lights on, people wearing capes, fun events going around. There were artists dressed in a Bumblebee, a Batman, a Superman, a Supergirl, a Thor and more superhero costumes! I was previously made aware of the interesting parties at Jenkins World but the experience was very different. People from all over the world had come together to celebrate the 15 years of success of an open source software. After partying from 5 to 7 we went back to the hotel. I spent some time to prepare the slides for the next day’s presentation and went to bed. Day 3 (Dec 5) The third and final day of conference began with Jenkins World Fun Run. I missed the keynote for being late and other setup required for the presentation. My laptop was broken so had to do all the setup for demo on a friend’s laptop. The situation felt like a Jenkins admin under fire for a production bug. After being under pressure for a while, took a break to admire the developer comics and had a chat with the graffiti painter. During lunch it was time for the GSoC presentation at the Jenkins community booth. All our presentation went well and we also interacted with real users. Then we had the GSoC Team pic at the Jenkins community booth. Later Abhyudaya and me gave our presentation at the lightning talks as well upon Mark Waite’s request. The event concluded with emotional goodbyes. All GSoC Students were invited for dinner at Corinthia Lisboa’s Soul Garden restaurant. The party comprised of Oleg, Mark and his lovely wife, Liam, Tracy, Alyssa and Olivier. We had a very nice conversation and I had a very delicious Bacalhau (cod fish) dish. Then bid final goodbye to everybody. It was a wonderful experience in a wonderful country among wonderful people. Hats off to the management team lead by Alyssa Tong and co. An event this big was carried out without any hiccups! Everybody contributed their part to the event which made it very interactive and fun. Checkout some of my swags: A big shout out to the Jenkins project and CloudBees for sponsoring this trip. Also thank you Jenkins and Google Summer of Code for support. :)

I had the privilege of being invited to DevOps World | Jenkins World 2019 for presenting the work I did during Google Summer of Code 2019. What follows is a day-by-day summary of an amazing trip to the conference. Day 0: December 1, 2019 I am an undergraduate student from New Delhi, India and had traveled to Lisbon to attend the conference. I had an early morning flight to Lisbon from Delhi via Istanbul. At the Airport, I met Parichay who had been waiting there from his connecting flight. After flying 8000 km, we reached Lisbon. We took a taxi to the hotel and were greeted there by one of my Google Summer of Code mentors, Oleg. After four months of working with him on my GSoC project, meeting him was an amazing experience. Later that day, after stretching our legs in the hotel, we met Long for an early dinner, who came to the hotel after exploring much of Lisbon. Day 1: Hackfest, December 2 Next morning, we all met for breakfast where we all got to taste some Pastel de Nata. We then took a cab to the Congress Centre for attending the Jenkins and Jenkins X hackfest. At the Hackfest, I met Mark, Joseph, Kasper, Andrey and other Jenkins contributors. I also met Oleg, this time together with his son and his wife. After our introductions, and a short presentation by Oleg, I started hacking on the Folder Auth plugin and made it possible to delete user sids from roles. The best part of hacking there was to get instant feedback on what I was working on. More and more people kept coming throughout the day. It was great to see so many people working hard to improve Jenkins. At the end, everyone presented what they had achieved that day. Having skipped lunch for some snacks, Oleg and others tried hard to get some pizza delivered without much success. After the Hackfest, everyone was hungry and most attendees including me went looking for nearby restaurants. Since it was early and most restaurants were not open yet, we all decided to have burgers. It was a great learning experience listening to and talking about Jenkins, Elasticsearch, Jira, GitHub and a lot of other things. After that, we took a taxi back to the hotel and I went to bed. Day 2: Contributor Summit, December 3 We had the Jenkins and Jenkins X contributor summit the next day. Me and Parichay took the bus to the Congress Centre in the morning. After registration, I got my ‘Speaker’ badge and the conference T-shirt. The contributor summit took place in the same hall as the Hackfest, but the seating arrangement was completely different and there were a lot more people. The summit started with everyone introducing themselves. It turned out that there were a lot of people from Munich. There were presentations and talks about all things Jenkins, Jenkins X and the Continuous Delivery Foundation by Kohsuke, Oleg, Joseph, Liam, Olivier, Wadek and others. I had no experience with Jenkins X which made the summit very interesting. After lunch, the talks were over, and everyone was free to join any session discussing various things about Jenkins. I attended the Cloud Native Jenkins and the Configuration-as-Code sessions. While some of the conference attendees were in the Contributor summit, the others were going through certifications and trainings. At around 5 o’clock in the evening, the summit and the trainings all got over and the expo hall was thrown open. On the entrance, there was a large stack of big DWJW bags. I did not realize why those bags were kept there. Since everyone was taking one, I took one as well. As soon as I went into the hall, I realized that those bags were for collecting swag. I had never seen anything like this where sponsors were just giving away T-shirts, stickers and other stuff. There were snacks and Kohsuke was cutting the extremely tasty 15 years of Jenkins cake. After having the cake, I went on a swag-collecting spree going from one sponsor booth to the other. This was an amazing experience, not only was I able to get cool stuff, I was also able to learn a lot about the software these companies made and how it fits into the DevOps pipeline. After the conference got over, me, Long and Parichay went to the Lisbon Mariott Hotel for the Eurodog party. After collecting another T-shirt, I went to the nearest restaurant (McDonald’s) with Andrey who I had earlier met at the Hackfest. Day 3: December 4 This was the first official day of the conference and it began with the keynote. There were over 900 people in the keynote hall. It was amazing to see so many people attending the conference. After the keynote got over, I went to several sessions throughout the day learning about how companies are using Jenkins and implementing DevOps tools. In the evening, we had the Sonatype Superparty which was a lot of fun. There were neon lights, arcade machines, VR experiences, superheroes and more swag. There was a lot of good food including pizzas and burgers and hot dogs. Superhero inspired desserts were very interesting. I was able to talk to Oleg and Wadek about the security challenges in Jenkins. During the party, I also got a chance to meet the CEO of CloudBees, Sacha Labourey. Day 4, December 5 This was the last day of the conference and it began with another keynote. After the keynote, I attended a very interesting talk on how the European Observatory built software for large telescopes using Jenkins. After that, I prepared for my talk on the work I did during Google Summer of Code 2019. I had my presentation in the community booth during the lunch time. Presenting in front of real people was an amazing experience and very different from the ones we had on Zoom chats for our GSoC evaluations. In the evening, I got another chance to present my project at the Jenkins Community Lightning Talks. After that, the conference came to an end and I went back to the hotel. After relaxing for some time, me, Parichay and Long were invited by Oleg to a dinner at Corinthia Hotel with Kohsuke, Mark and his wife, Tracy, Alyssa, and Liam. Unfortunately, Long couldn’t attend the dinner because he had the flight back earlier that evening. After the amazing dinner, I thanked everyone for such an amazing trip and said goodbye. DWJW was the best experience I’ve ever had. I was able to learn about a lot of new things and talk to some amazing people. In the end, I would like to especially thank Oleg for helping me throughout and making it possible for me to attend such a wonderful conference. I would like to thank my other mentors Runze Xia and Supun for their support in my Google Summer of Code project. I would like to thank Google for organizing Google Summer of Code, everyone at Jenkins project for sponsoring my travel, and CloudBees for inviting me to the conference. Looking forward to seeing you all again soon!

Google Summer of Code is much more than a summer internship program, it is a year-round effort for the organization and some community members. Now, after the DevOps World | Jenkins World conference in Lisbon and final retrospective meetings, we can say that GSoC 2019 is officially over. We would like to start by thanking all participants: students, mentors, subject matter experts and all other contributors who proposed project ideas, participated in student selection, in community bonding and in further discussions and reviews. Google Summer of Code is a major effort which would not be possible without the active participation of the Jenkins community. In this blogpost we would like to share the results and our experience from the previous year. Results Five GSoC projects were successfully completed this year: Role Strategy Plugin Performance Improvements, Plugins Installation Manager CLI Tool/Library, Working Hours Plugin - UI Improvements, Remoting over Apache Kafka with Kubernetes features, Multi-branch Pipeline support for Gitlab SCM. We will talk about the projects a little later in the document. Project details We held the final presentations as Jenkins Online Meetups in late August and Google published the results on Sept 3rd. The final presentations can be found here: Part 1, Part 2, Part 3. We also presented the 2019 Jenkins GSoC report at the DevOps World | Jenkins World San Francisco and at the DevOps World | Jenkins World 2019 Lisbon conferences. In the following sections, we present a brief summary of each project, links to the coding phase 3 presentations, and to the final products. Role Strategy Plugin Performance Improvements Role Strategy Plugin is one of the most widely used authorization plugins for Jenkins, but it has never been famous for performance due to architecture issues and regular expression checks for project roles. Abhyudaya Sharma was working on this project together with hist mentors: Oleg Nenashev, Runze Xia and Supun Wanniarachchi. He started the project from creating a new Micro-benchmarking Framework for Jenkins Plugins based on JMH, created benchmarks and achieved a 3501% improvement on some real-world scenarios. Then he went further and created a new Folder-based Authorization Strategy Plugin which offers even better performance for Jenkins instances where permissions are scoped to folders. During his project Abhyudaya also fixed the Jenkins Configuration-as-Code support in Role Strategy and contributed several improvements and fixes to the JCasC Plugin itself. Project page Blog posts: Micro-benchmarking Framework for Jenkins Plugins, Introducing new Folder Authorization Plugin, Performance Improvements to Role Strategy Plugin Final evaluation: slides, video Source code: Role Strategy Plugin, Folder Authorization Plugin Plugins Installation Manager CLI Tool/Library Natasha Stopa was working on a new CLI tool for plugin management, which should unify features available in other tools like install-plugins.sh in Docker images. It also introduced many new features like YAML configuration format support, listing of available updates and security fixes. The newly created tool should eventually replace the previous ones. Natasha’s mentors: Kristin Whetstone, Jon Brohauge and Arnab Banerjee. Also, many contributors from Platform SIG and JCasC plugin team joined the project as a key stakeholders and subject-matter experts. Project page Blog posts: alpha release announcement, coding phase 2 updates Final evaluation: slides, video Source code: Plugin installation manager tool Working Hours Plugin - UI Improvements Jenkins UI and frontend framework are a common topic in the Jenkins project, especially in recent months after the new UX SIG was established. Jack Shen was working on exploring new ways to build Jenkins Web UI together with his mentor Jeff Pearce. Jack updated the Working Hours Plugin to use UI controls provided by standard React libraries. Then he documented his experienced and created template for plugins with React-based UI. Project page Blog posts: Updates on Working Hours Plugin UI, React Plugin Template Final evaluation: slides, video Source code: Working Hours Plugin, Template for Jenkins plugins with React-based UI Remoting over Apache Kafka with Kubernetes features Long Le Vu Nguyen was working on extended Kubernetes support in the Remoting over Apache Kafka Plugin. His mentors were Andrey Falco and Pham vu Tuan who was our GSoC 2018 student and the plugin creator. During this project Long has added a new agent launcher which provisions Jenkins agents in Kubernetes and connects them to the controller. He also created a Cloud API implementation for it and a new Helm chart which can provision Jenkins as entire system in Kubernetes, with Apache Kafka enabled by default. All these features were released in Remoting over Apache Kafka Plugin 2.0. Project page Blog post for [Remoting over Apache Kafka Plugin 2.0 Final evaluation: slides, video Plugin source code Multi-branch Pipeline support for Gitlab SCM Parichay Barpanda was working on the new GitLab Branch Source Plugin with Multi-branch Pipeline Jobs and Folder Organisation support. His mentors were Marky Jackson-Taulia, Justin Harringa, Zhao Xiaojie and Joseph Petersen. The plugin scans the projects, importing the pipeline jobs it identifies based on the criteria provided. After a project is imported, Jenkins immediately runs the jobs based on the Jenkinsfile pipeline script and notifies the status to GitLab Pipeline Status. This plugin also provides GitLab server configuration which can be configured in Configure System or via Jenkins Configuration as Code (JCasC). read more about this project in the GitLab Branch Source 1.0 announcement. Project page Coding phase 3 presentation Gitlab Branch Source Plugin, Gitlab API plugin Projects which were not completed Not all projects have been completed this year. We were also working on Artifact Promotion plugin for Jenkins Pipeline and on Cloud Features for External Workspace Manager Plugin, but unfortunately both projects were stopped after coding phase 1. Anyway, we got a lot of experience and takeaways in these areas (see linked Jira tickets!. We hope that these stories will be implemented by Jenkins contributors at some point. Google Summer of Code 2020 maybe? Running the GSoC program at our organization level Here are some of the things our organization did before and during GSoC behind the scenes. To prepare for the influx of students, we updated all our GSoC pages and wrote down all the knowledge we accumulated over the years of running the program. We started preparing in October 2018, long before the official start of the program. The main objective was to address the feedback we got during GSoC 2018 retrospectives. Project ideas. We started gathering project ideas in the last months of 2018. We prepared a list of project ideas in a Google doc, and we tracked ownership of each project in a table of that document. Each project idea was further elaborated in its own Google doc. We find that when projects get complicated during the definition phase, perhaps they are really too complicated and should not be done. Since we wanted all the project ideas to be documented the same way, we created a template to guide the contributors. Most of the project idea documents were written by org admins or mentors, but occasionally a student proposed a genuine idea. We also captured contact information in that document such as GitHub and Gitter handles, and a preliminary list of potential mentors for the project. We embedded all the project documents on our website. Mentor and student guidelines. We updated the mentor information page with details on what we expect mentors to do during the program, including the number of hours that are expected from mentors, and we even have a section on preventing conflict of interest. When we recruit mentors, we point them to the mentor information page. We also updated the student information page. We find this is a huge time saver as every student contacting us has the same questions about joining and participating in the program. Instead of re-explaining the program each time, we send them a link to those pages. Application phase. Students started to reach out very early on as well, many weeks before GSoC officially started. This was very motivating. Some students even started to work on project ideas before the official start of the program. Project selection. This year the org admin team had some very difficult decisions to make. With lots of students, lots of projects and lots of mentors, we had to request the right number of slots and try to match the projects with the most chances of success. We were trying to form mentor teams at the same time as we were requesting the number of slots, and it was hard to get responses from all mentors in time for the deadline. Finally we requested fewer slots than we could have filled. When we request slots, we submit two numbers: a minimum and a maximum. The GSoC guide states that: The minimum is based on the projects that are so amazing they really want to see these projects occur over the summer, and the maximum number should be the number of solid and amazing projects they wish to mentor over the summer. We were awarded minimum. So we had to make very hard decisions: we had to decide between "amazing" and "solid" proposals. For some proposals, the very outstanding ones, it’s easy. But for the others, it’s hard. We know we cannot make the perfect decision, and by experience, we know that some students or some mentors will not be able to complete the program due to uncontrollable life events, even for the outstanding proposals. So we have to make the best decision knowing that some of our choices won’t complete the program. Community Bonding. We have found that the community bonding phase was crucial to the success of each project. Usually projects that don’t do well during community bonding have difficulties later on. In order to get students involved in the community better, almost all projects were handled under the umbrella of Special Interest Groups so that there were more stakeholders and communications. Communications. Every year we have students who contact mentors via personal messages. Students, if you are reading this, please do NOT send us personal messages about the projects, you will not receive any preferential treatment. Obviously, in open source we want all discussions to be public, so students have to be reminded of that regularly. In 2019 we are using Gitter chat for most communications, but from an admin point of view this is more fragmented than mailing lists. It is also harder to search. Chat rooms are very convenient because they are focused, but from an admin point of view, the lack of threads in Gitter makes it hard to get an overview. Gitter threads were added recently (Nov 2019) but do not yet work well on Android and iOS. We adopted Zoom Meetings towards the end of the program and we are finding it easier to work with than Google Hangouts. Status tracking. Another thing that was hard was to get an overview of how all the projects were doing once they were running. We made extensive use of Google sheets to track lists of projects and participants during the program to rank projects and to track statuses of project phases (community bonding, coding, etc.). It is a challenge to keep these sheets up to date, as each project involves several people and several links. We have found it time consuming and a bit hard to keep these sheets up to date, accurate and complete, especially up until the start of the coding phase. Perhaps some kind of objective tracking tool would help. We used Jenkins Jira for tracking projects, with each phase representing a separate sprint. It helped a lot for successful projects. In our organization, we try to get everyone to beat the deadlines by a couple of days, because we know that there might be events such as power outages, bad weather (happens even in Seattle!), or other uncontrolled interruptions, that might interfere with submitting project data. We also know that when deadlines coincide with weekends, there is a risk that people may forget. Retrospective. At the end of our project, we also held a retrospective and captured some ideas for the future. You can find the notes here. We already addressed the most important comments in our documentation and project ideas for the next year. Recognition Last year, we wanted to thank everyone who participated in the program by sending swag. This year, we collected all the mailing addresses we could and sent to everyone we could the 15-year Jenkins special edition T-shirt, and some stickers. This was a great feel good moment. I want to personally thank Alyssa Tong her help on setting aside the t-shirt and stickers. Mentor summit Each year Google invites two or more mentors from each organization to the Google Summer of Code Mentor Summit. At this event, hundreds of open-source project maintainers and mentors meet together and have unconference sessions targeting GSoC, community management and various tools. This year the summit was held in Munich, and we sent Marky Jackson and Oleg Nenashev as representatives there. Apart from discussing projects and sharing chocolate, we also presented Jenkins there, conducted a lightning talk and hosted the unconference session about automation bots for GitHub. We did not make a team photo there, so try to find Oleg and Marky on this photo: GSoC Team at DevOps World | Jenkins World We traditionally use GSoC organization payments and travel grants to sponsor student trips to major Jenkins-related events. This year four students traveled to the DevOps World | Jenkins World conferences in San-Francisco and Lisbon. Students presented their projects at the community booth and at the contributor summits, and their presentations got a lot of traction in the community! Thanks a lot to Google and CloudBees who made these trips possible. You can find a travel report from Natasha Stopa here, more travel reports are coming soon. Conclusion This year, five projects were successfully completed. We find this to be normal and in line with what we hear from other participating organizations. Taking the time early to update our GSoC pages saved us a lot of time later because we did not have to repeat all the information every time someone contacted us. We find that keeping track of all the mentors, the students, the projects, and the meta information is a necessary but time consuming task. We wish we had a tool to help us do that. Coordinating meetings and reminding participants of what needs to be accomplished for deadlines is part of the cheerleading aspect of GSoC, we need to keep doing this. Lastly, I want to thank again all participants, we could not do this without you. Each year we are impressed by the students who do great work and bring great contributions to the Jenkins community. GSoC 2020? Yes, there will be Google Summer of Code 2020! We plan to participate, and we are looking for project ideas, mentors and students. Jenkins GSoC pages have been already updated towards the next year, and we invite everybody interested to join us next year! Main page with all contacts GSoC 2020 Project Ideas GSoC 2020 Call for Mentors and Project Ideas Information for students and mentors

I was fortunate enough to participate in the Google Summer of Code 2019 as a mentor and org admin. This was great and I wanted to share in hopes of encouraging more people to join. You can learn more about the Google Summer of Code here: https://jenkins.io/projects/gsoc/ Community Bonding The first phase of the project is the community bonding phase. This is where the student and other mentors come together to lay out the plan for the project. It is important to set expectations and ensure that the student is well aware of what will take place and also made to feel welcome. Parichay Barpanda was the student and he was super awesome from the get go. The project he was working on was the Gitlab Branch Source Plugin. More can be found here: jenkinsci/gitlab-branch-source-plugin From the mentor side it was myself and Justin Harringa. Justin was just amazing throughout this project and I seriously could not have done this without him. He was encouraging, empathetic and just all around great. I would gladly serve with him again. We laid out our plan and guidance and got to work. First Evaluations The first evaluation was quickly upon us and Parichay was ready! The work he put in was nothing shy of amazing. We did our 1st demo and he really rocked it. A video of that demo can be found on : Youtube Second Evaluations There was not much time to rest before we realized that phase II end was upon us but Parichay was ready. Again, he nailed it. That demo can be found here Mentors Submit Final Evaluations We had our final evaluation and at this point Parichay was seasoned. He was getting issues assigned to him, working on little bug fixes and setting his roadmap for features. He absolutely blew Justin and I away. Parichay’s final evaluation demo can be seen here At the conclusion of the final demo’s, Justin and I met and went over Parichay’s final evaluation. At this point we had met twice a week for several months, we have reviewed code daily, we had community involvement and most of all we had seen Parichay grow into a seasoned software developer. Justin and I were without a doubt passing Parichay on his entire body of work. I am actually tearing up typing this because I am so proud of Parichay. Org Admin Being an org admin for the 2019 Google Summer of Code project for the Jenkins organization was truly rewarding and couldn’t have been accomplished without the help from Oleg Nenashev, Martin d’Anjou, Jeff Pearce and Lloyd Chang. As an org admin we handled issues with mentors, community members and disagreements involving work. These items were only a few and as a team we handled them accordingly. We regularly met to discuss and plan. Coordinating and dealing with a project like Google Summer of Code is no small feat but this team made it super easy and I am so thankful for them and all that I learned. Closing In looking back at this experience I am so grateful for the opportunity I was given. This was such a rewarding experience to not only be able to mentor but also be an org admin. Not only will I be back next year (we are already in the planning stages) but I highly encourage people reading this to consider joining. You will not be disappointed. I am so thankful for all the students, mentors and fellow org admins. Your dedication to open source is so valued. You showed and continue to show what this project is all about, and that is being welcoming, open and transparent. Helping people grow as individuals while learning skills is what I love about this community. Thank you to everyone and I hope your futures are bright!

The task for my Google Summer of Code program was to improve the performance of the Role Strategy Plugin. The performance issues for Role Strategy Plugin had been reported multiple times on Jenkins JIRA. With a large number of roles and with complex regular expressions, a large slow-down was visible on the Web UI. Even before GSoC started, there were a number of patches which tried to improve performance of the plugin (by Deepansh Nagaria and others). At the time, there was no way to reliably measure improvements in performance. Therefore, we started by creating a framework for running micro-benchmarks on Jenkins Plugins. Benchmarks using the framework were added to the Role Strategy Plugin find performance critical parts of the plugins and to measure the improvements of a change. This blog post summarizes the changes that were made and performance improvements measured. Caching matching roles A couple of major changes were made to the Role Strategy Plugin to improve its performance. First, we started collection of roles that matched a given project name. The Role Strategy plugin before version 2.12 used to run over regular expressions for every role that it had for every permission checking request it got. Storing this produced set of roles in the memory provides us large improvements in performance and avoids repeated matching of project names with regular expressions. For keeping the plugin working securely, we invalidate the cache whenever any update is made to the roles. After this change, we were able to observe performance improvements of up to 3300%. These improvements were visualized using JMH Visualizer. More information is available at pull request on GitHub: https://github.com/jenkinsci/role-strategy-plugin/pull/81 Calculating Implying Permisions when plugin is loaded Jenkins' permission model allows one permissions to imply other permissions. When a permission check is made, we need to check if the user has any of permissions that would imply this permisison. For every permission checking request that that the Role Strategy, it used to calculate all the implying permissions. To avoid this, we now calculate and store implying permissions for every permission in the Jenkins system when the plugin gets loaded. After both of these changes, we were able to experience improvements of up to 10000%. The benchmark results show it better: More information about this change can be found at the GitHub pull request: https://github.com/jenkinsci/role-strategy-plugin/pull/83 Both of these changes were integrated into the Role Strategy Plugin and the improvements can be experienced starting with version 2.13. Bonus: Configuration-as-Code export now works for Role Strategy With Configuration-as-Code plugin version 1.24 and above, export of your configuration as YAML now works! As an alternative to Role Strategy Plugin, I also created the brand new Folder Authorization Plugin. You can check out the blog post for more information about the plugin. Links and Feedback I would love to hear your comments and suggestions. Please feel free to reach out to me through either the Role Strategy Plugin Gitter chat or through Jenkins Developer Mailing list. Presentation slides for final evaluation of GSoC The Folder Authorization Plugin Demo for the final evaluations

Jenkins turns 15 years old! Jenkins World brings together DevOps thought leaders, IT executives, continuous delivery practitioners and the Jenkins community and ecosystem in one global event, providing attendees with the opportunity to learn, explore, network face-to-face and help shape the next evolution of Jenkins development and solutions for DevOps. There is also the Jenkins Contributor Summit in San Francisco. The Jenkins Contributor Summit is the place where current and future contributors get together to discuss, learn and collaborate on the latest and greatest efforts within Jenkins project. The morning portion of the summit is a mix of presentations by the core contributors. The presentations highlight what each effort is about and what community members can do to help. In the afternoon breakout sessions with Birds of a Feather tables for in-depth discussion, and collaboration with sub-project contributors. I feel very honored to have been a part of this. Day 1 Day one started with the contributor summit. This was a chance for everyone to get together and talk about contributions and put faces to names. Most people I had only met via video chat or on gitter so I was super excited. We gathered to hear about the start of the Jenkins open source landscape. Next up was the BoF/Unconference. I was leading these sessions and I felt they went really well. We had fellow org admins Martin d’Anjou and Jeff Pearce give a talk about Google Summer of Code projects. Google Summer of Code student Natasha Stopa presented her project, Plugin Installation Manager Library/CLI Tool. This is a super cool project and very well received in the community. We closed out the session with a presentation from Steven Terrana from Booz Allen Hamilton and the awesome Jenkins Templating Engine. If you have not had a chance to try this, please make sure you do at https://github.com/boozallen/jenkins-templating-engine. Main Expo Hall Day two and onward saw me and other Jenkins org admins in the Ask the Expert booth for the Jenkins community. This was a really cool experience and gave me a chance to hear about things the community is working on and help with issues they are facing. There were a range of questions from Jenkins X to many of the plugins I maintain such and the Jenkins Prometheus and the Sysdig Secure Scanning plugins. There were also a lot of Kubernetes questions. There is a lot of marketing data regarding the increased usage of Kubernetes but I was seriously surprised by the massive interest in Jenkins on Kubernetes. Of course there were opportunities for selfie requests. Lunch time demos got underway and we had a busy schedule. First up was the awesome Mark Waite to talk about the Git plugin. A lot of people use git in Jenkins. Thank you so much for all that you do Mark. Jenkins org admin Martin d’Anjou was next on deck to talk about the Google Summer of Code. So amazing to think that the Google Summer of Code is also in its 15th year like Jenkins! Natasha Stopa is a Google Summer of Code student and she presented her project Plugin Installation Manager Library/CLI Tool. Natasha really put a lot of hard work in to this plugin and it was really awesome to see the turn out and support during her presentation. Finally there was me. I presented the Sysdig Secure Scanning Jenkins plugin which I am a maintainer of. I thank everyone who attended Right after the lunch time demos I also oversaw the Jenkins open space. This was an opportunity for the community to talk about items and let them flow organically. I really enjoyed this session and felt it was also well received. We closed out the day and the event with a picture of some of the Jenkins org admins and Google Summer of Code students. Missing from this photos are fellow org admins, Lloyd Chang and Oleg Nenashev Closing This was an amazing experience. Huge thanks to CloudBees, the Jenkins community, Google Summer of Code, Tracy Miranda, Alyssa Tong and my employer Sysdig. To think Jenkins is 15 years old is amazing! There has been so much accomplished and the future is so bright. I am so thankful for the opportunity to serve and be a part of the open source community. Here’s to 15 more years all! If you are interested in joining any one of the Jenkins open source special interest groups, look here. We can use your help: https://jenkins.io/sigs/ If you are interested in joining the Summer of Code, look here: https://jenkins.io/projects/gsoc/ If you want to chat with us, find us here: https://jenkins.io/chat/ Or if you want to email us, reach out at: https://jenkins.io/mailing-lists/ Some photos outtakes:

The template’s main repo is at React Plugin Template This template is part of the project Working Hours UI Improvement during Google Summer of Code 2019, which improved the UI of Working Hours Plugin using this pattern to develop Jenkins plugins with React. The Working Hours Plugin repository can be found at Working Hours Plugin. Overview Developing plugin for Jenkins has always been easy to do with its Jelly based UI render system, but Jelly seems to be pretty heavy when we want to use more modernized frameworks like React, or if we need to make the plugin UI more customized. This is what this template is built for. And with React integrated, development of Jenkins plugin is more modernized, developer can now use tons of React libraries, the way to use libraries is now tinier and safer with webpack, in short, coding with Jenkins plugin can be much easier. Features Feature Summary React Integrated React is integrated, you can take full control of the UI Using Iframe Using iframe can create a new javascript env, we can get rid of some side effects of some polyfills which was added globally.(such as Prototype.js) Maven Lifecycle npm commands are integrated into Maven lifecycle with help of Frontend Maven Plugin Webpack Webpack helps us reduce the size of the bundle, also avoids pollution on the global namespace. Jenkins Crumb attached Crumb is attached to Axios client, now you can send requests in the way you used to do in React. Express as devserver You can run your react app in a standalone page so you can develop in webpack hot reload mode, also with webpack proxy, the standalone app is still accessible to the jenkins dev server. Axios as http client Axios hugely simplify the way to make requests. Screenshots Example Plugin UI Management Link Getting Started Clone the repo: git clone https://github.com/jenkinsci/react-plugin-template.git cd react-plugin-template Install the Maven dependencies and node modules. mvn install -DskipTests Run standalone React app with hot reload npm run start Run plugin mvn hpi:run -Dskip.npm -f pom.xml Send HTTP requests As Crumb Issuer is default enabled in Jenkins and each ajax request is required to contain a Jenkins Crumb in request header, so be sure to use the axiosInstance which is already set up with Jenkins Crumb and exported at src/main/react/app/api.js. export const apiGetData = () => { return axiosInstance.post("/data"); }; Or if you want to use your own http client, remember to add the Jenkins Crumb to your request’s header, the Crumb’s key and content could be found at src/main/react/app/utils/urlConfig.js, then you can set the header like below. const headers = {}; const crumbHeaderName = UrlConfig.getCrumbHeaderName(); if (crumbHeaderName) { headers[crumbHeaderName] = UrlConfig.getCrumbToken(); } Write your own request handler Now you can customize your request pattern as you want, also we need to write a handler. Jenkins is using stapler to preprocess the requests, so if you need a request handler. For example and also in this template, you can use an Action class to create a sub-url, and then a StaplerProxy to proxy the request like a router. More info about handlers can be found in the Stapler Reference. Example handler ManagementLink would get the request and then hand it off to the PluginUI @Extension public class PluginManagementLink extends ManagementLink implements StaplerProxy { PluginUI webapp; public Object getTarget() { return webapp; } public String getUrlName() { return "react-plugin-template"; } } PluginUI, stapler would then find methods in the target class, in this case, it finds doDynamic, then we can choose the next handler by return the methods result, in this case, getTodos or setTodos, and PluginUI just function like a url router. public class PluginUI{ public HttpResponse doDynamic(StaplerRequest request) { ... List params = getRequestParams(request); switch (params.get(0)) { case "get-todos": return getTodos(); case "set-todos": return setTodos(request); } ... } } Data Persistence You can save your data with a descriptor @Extension public class PluginConfig extends Descriptor implements Describable And after each time you change data, call save() to persist them. public void setTodos( @CheckForNull List value) { this.todos = value; save(); } And in your handler, you can get the config class by calling config = ExtensionList.lookup(PluginConfig.class).get(0); Customize your plugin Be sure to modify all the occurrence of react-template At org/jenkinsci/plugins/reactplugintemplate/PluginUI/index.jelly, change the iframe’s id and its source url. At src/main/react/app/utils/urlConfig.js change At src/main/react/server/config.js, change the proxy route. At src/main/react/package.json, change the start script’s BASE_URL At pom.xml, change the artifactId At org/jenkinsci/plugins/reactplugintemplate/PluginManagementLink.java, change names. Also use the same value to modify the occurrence in src\main\react\app\utils\urlConfig.js. Customize a page for your plugin A management Link is recommended, which would get your plugin a standalone page, along with a entry button in the /manage system manage page. How does this template work? This template is putting a webpack project inside a Maven project, and this template is just chaining the build result by copy the webpack output to the plugin’s webapp folder to make it accessible from the iframe, then Jelly render the iframe and the client gets the Plugin UI. Why iframe? Over time, Jenkins has added a lot of various javascript libraries to every regular page, which now causes problems for using modern Javascript tooling and as such, we decided to inline the new react based pages in their own sandbox which prevents collisions with other libraries, and maybe the iframe is a good sandbox case. Links Github: React Plugin Template Github: Working Hours Plugin

The GitLab Branch Source Plugin has come out of its beta stage and has been released to the Jenkins update center. It allows you to create job based on GitLab user or group or subgroup project(s). You can either: Import a single project’s branches as jobs from a GitLab user/group/subgroup (Multibranch Pipeline Job) Import all or a subset of projects as jobs from a GitLab user/group/subgroup (GitLab Group Job or GitLab Folder Organization) The GitLab Group project scans the projects, importing the pipeline jobs it identifies based on the criteria provided. After a project is imported, Jenkins immediately runs the jobs based on the Jenkinsfile pipeline script and notifies the status to GitLab Pipeline Status. This plugin unlike other Branch Source Plugins provides GitLab server configuration which can be configured in Configure System. Jenkins Configuration as Code (JCasC) can also be used to configure the server. To learn more about server configuration see my previous blog post. Requirements Jenkins - 2.176.2 (LTS) GitLab - v11.0+ Creating a Job To create a Multibranch Pipeline Job (with GitLab branch source) or GitLab Group Job, you must have GitLab Personal Access Token added to the server configuration. The credentials is used to fetch meta data of the project(s) and to set up hooks on GitLab Server. If the token has admin access you can also set up System Hooks while Web Hooks can be set up from any user token. Create a Multibranch Pipeline Job Go to Jenkins > New Item > Multibranch Pipeline > Add Source > GitLab Project Server - Select your desired GitLab server from the dropdown, needs to be configured before creating this job. Checkout Credentials - Add credentials of type SSHPrivateKey or Username/Password if there are any private projects to be built by the plugin. If all projects are public then no checkout credentials required. Checkout credential is different from the credential (of type GitLab Personal Access Token) setup in GitLab server config. Owner - Can be a user, group or subgroup. Depending on this the Projects field is populated. Projects - Select the project you want to build from the dropdown. Behaviours - These traits are very powerful tool to configure the build logic and post build logic. We have defined new traits. You can see all the information in repository documentation. Save and wait for the branches indexing. You are free to navigate from here, the job progress is displayed to the left hand side. After the indexing, the imported project listed all the branches, merge requests and tags as jobs. On visiting each job, you will find some action items on the left hand side: You can trigger the job manually by selecting Build Now. You can visiting the particular branch/merge request/tag on your GitLab Server by selecting the corresponding button. Create a GitLab Group Job Type Go to Jenkins > New Item > GitLab Group You can notice the configuration is very similar to Multibranch Pipeline Job with only Projects field missing. You can add all the projects inside your Owner i.e. User/Group/Subgroup. The form validation will check with your GitLab server if the owner is valid. You can add Discover subgroup project trait which allows you to discover this child projects of all subgroups inside a Group or Subgroup but this trait is not applicable to User. While indexing, web hook is created in each project. GitLab Api doesn’t support creation of Group web hooks so this plugin doesn’t support that feature which is only available in GitLab EE. You can now explore your imported projects, configuring different settings on each of those folders if needed. GitLab Pipeline Status Notification GitLab is notified about build status from the point of queuing of jobs. Success - the job was successful Failure - the job failed and the merge request is not ready to be merged Error - something unexpected happened; example: the job was aborted in Jenkins Pending - the job is waiting in the build queue On GitLab Pipeline status are hyperlinks to the corresponding Jenkins job build. To see the Pipeline Stages and the console output you will be required to visit your Jenkins server. We also planned to notify the pipeline stages to GitLab but it came with some drawbacks which has been addressed so far but there is future plan to add it as trait. You can also skip notifying GitLab about the pipeline status by selecting Skip pipeline status notifications from the traits list. Merge Requests Implementing support for Merge Requests for the projects was challenging. First, MRs are of 2 types i.e. Origin branches and Forked Project branches so there had to be different implementation for each head. Second, MRs from forks can be from untrusted sources, so a new strategy Trust Members was implemented which allows CI to build MRs only from trusted users who have accesslevel of Developer / Maintainer / Owner. Third, MRs from forks do not support pipeline status notification due to GitLab issue, see this. You can add a trait Log Build Status as Comment on GitLab that allows you to add a sudo user (leave empty if you want owner user) to comment on the commit/tag/mrs the build result. To add a sudo user your token must have admin access. By default only failure/error are logged as comment but you can also enable logging of success build by ticking the checkbox. Sometimes, Merge Requests fail due to external errors so you want to trigger rebuild of mr by commenting jenkins rebuild. To enable this trigger add the trait Trigger build on merge request comment. The comment body can be changed in the trait. For security reasons, commentor should have Developer / Maintainer / Owner accesslevel in the project. Hooks Web hooks are automatically created on your projects if configured to do so in server configuration. Web hooks are ensured to pass through a CSRF filter. Jenkins listens to web hooks on the path /gitlab-webhook/post. On GitLab web hooks are triggered on the following events: Push Event - when a commit or branch is pushed Tag Event - when a new tag is created Merge Request Event - when a merge request is created/updated Note Event - when a comment is made on a merge request You can also set up System Hooks on your GitLab server if your token has admin access. System hooks are triggered when new projects are created, Jenkins triggers a rescan of the new project based on the configuration and sets up web hook on it. Jenkins listens to system hooks on the path /gitlab-systemhook/post. On GitLab system hooks are triigered on Repository Update Events. You can also use Override Hook Management mode trait to override the default hook management and choose if you want to use a different context (say Item) or disable it altogether. Job DSL and JCasC You can use Job DSL to create jobs. Here’s an example of Job DSL script: organizationFolder('GitLab Organization Folder') { description("GitLab org folder created with Job DSL") displayName('My Project') // "Projects" organizations { gitLabSCMNavigator { projectOwner("baymac") credentialsId("i<3GitLab") serverName("gitlab-3214") // "Traits" ("Behaviours" in the GUI) that are "declarative-compatible" traits { subGroupProjectDiscoveryTrait() // discover projects inside subgroups gitLabBranchDiscovery { strategyId(3) // discover all branches } originMergeRequestDiscoveryTrait { strategyId(1) // discover MRs and merge them with target branch } gitLabTagDiscovery() // discover tags } } } // "Traits" ("Behaviours" in the GUI) that are NOT "declarative-compatible" // For some 'traits, we need to configure this stuff by hand until JobDSL handles it // https://issues.jenkins.io/browse/JENKINS-45504 configure { def traits = it / navigators / 'io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator' / traits traits You can also use JCasC to directly create job from a Job DSL script. For example see the plugin repository. How to talk to us about bugs or new features? This project uses Jenkins JIRA to track issues. You can file issues under gitlab-branch-source-plugin component. Send your mail in the Developer Mailing list. Join our Gitter channel. Future work Actively maintain GitLab Branch Source Plugin and take feedbacks from users to improve the plugin’s user experience. Extend support for GitLab Pipeline to Blueocean. Resources GitLab API Plugin GitLab API Plugin Wiki GitLab Branch Source Plugin Project Summary GitHub Branch Source Plugin Release Thank you Jenkins and Google Summer of Code :)