Google Summer of Code (GSoC) 2022: Call for organizers, mentors, and project ideas

Hi All! Much like the past 5 years, we are planning to participate in GSoC 2022.

About GSoC: GSoC is a mentorship program focused on welcoming new contributors into the community and helping them learn best practices that will help them be long term OSS contributors.
GSoC is an annual, global program that has been for college students. In 2022 GSoC is expanding its program to encourage all newcomers of open source that are 18 years and older. The program will no longer be solely focused on university students or recent graduates.

Important dates:

  • Project application registration opens in February 2022
  • Registration for GSoC contributors opens in April 2022. See eligibility here

2022 will be the sixth year the Jenkins project participates in GSoC. As we prepare for this program, we are looking for volunteers in the following areas:

  • Organization administrators (Org admins): This role is to make sure the Project Ideas list is solid. Org admins are the final authority about matters such as which GSoC contributor projects will be accepted, who will mentor whom, and what the end date will be for a coding project.

  • Topics & Mentors: Here’s how to submit project ideas

If you have any questions, or want to get involved, there is a Gitter channel and a dedicated mailing list. Please join the Jenkins GSoC mailing list if you would like to be kept up to date on GSoC information.

Lastly, Oleg Nenashev, the driver of Jenkins GSoC for the past years, will be hosting a walk thru of GSoC best practices. This would be great if you’re thinking about joining me as an org admin. More to come on this soon.



Hi All,

Happy New Year!

I wanted to share the project ideas as it stands at the moment. We are in need of additional mentors, as shown below. And of course, additional project ideas/mentors are welcome.

1 - Jenkinsfile Runner Action for GitHub Actions

Mentors: Oleg Nenashev, Kris Stern

2 - Automatic Specification Generator for Jenkins REST API

Mentors: Kristin Whetstone, additional mentor(s) needed

3 - Plugin Installation Manager Tool Improvements

Mentors needed

4 - Doc Generator

Mentors: Mark Waite, additional mentor(s) needed

5 - Configuration as Code Drift Detector

Mentors: Jean-Marc Meessen, additional mentor(s) needed

Thank you,

1 Like

based on Parsing a REST API bad request HTML-formatted response I wonder if @martinda would have any interest in getting involved and helping out.

Hi. Thanks for thinking of me. I am interested in the topic. Let me review how GSoC works. It has changed since I last participated.

Thank you @martinda for considering. I’m hoping to have project ideas and mentors nailed down by mid next week if that works for you.

I’d really love to help out, I love helping people get involved in coding and open source, but I’ve just over-committed myself too much again this year. Plus generally, my timezone doesn’t work with most of the GSOC students.

If we get desperate for plugin manager tool I can probably help out, but I don’t think its the best plan

I’d like to add one more project idea to the list

6 - Automatic git cache maintenance on the controller

Recent versions of command line git (since 2.30.0) have a set of commands for “git maintenance” that can be used to regularly update and maintain the contents of a git repository. I think that a Google Summer of Code participant could review the features available from “git maintenance” and identify ways that the Jenkins controller could use those features to manage the cached copies of git repositories.

1 Like

I’d like to add one more project idea to the list.

Automating plugin build metadata updates

The Jenkins ecosystem combines a monolithic core with a modular plugin system. True, this design provides a great degree of flexibility and robustness, yet also it poses challenges to propagating large-scale changes throughout the ecosystem. The lack of automation has led to many plugins falling behind with regard to ecosystem-wide migrations. This project proposes the creation of a new tool to apply generic transformations across the Jenkins ecosystem. Example transformations include:

  • Ensuring that each plugin has a Jenkinsfile that conforms to the latest best practices from the Jenkins infrastructure team, including the use of containerized builds
  • Keeping the minimum Jenkins version reasonably current
  • Updating the plugin parent POM to the latest version
  • Migrating from explicit dependency versions to the Jenkins plugin BOM
  • Enabling incrementals
  • Updating plugin SCM URLs to conform to the latest GitHub best practices
  • Migrating from HTTP to HTTPs URLs wherever possible
  • Converting API dependencies to plugin dependencies
  • Replacing transitional <table>-based markup with <div>-based markup
  • Replacing JSR 305 annotations with SpotBugs annotations
  • Replacing deprecated JUnit assertions with Hamcrest assertions
  • Replacing deprecated Mockito method calls with non-deprecated equivalents
  • Replacing deprecated HTMLUnit method calls with non-deprecated equivalents
  • Migrating from JUnit 3 to JUnit 4
  • Replacing HudsonTestCase with JenkinsRule
  • Replacing RestartableJenkinsRule with JenkinsSessionRule
  • Replacing Guava, Apache Commons, and Joda Time with Java Platform equivalents

The scope of this project is to create a generic tool for applying these types of transformations against Jenkins plugins, validating the applied transformations, and creating pull requests with the results. While not all of the transformations described above will be implemented as part of this project, it is expected that a subset of the above list will be implemented to prove the viability of the newly-created tool.

Note that some of these transformations depend on other transformations, so a stack of transformations must be created and validated prior to creating the pull request.

The transformations range from editing Maven pom.xml files to applying automated refactorings to Java source code. It is suggested that XML and Java manipulation frameworks like JDOM and Refaster be used to implement the transformations described above.


Hello. As announced in the Jenkins developer mailing list, I decided to NOT participate in GSoC 2022 as org admin in Jenkins. The reasons are lack of time due to personal situation, poor communication and timezone overlap with other org admins. I am also not abler to participate in Advocacy&Outreach SIG meetings which were reportedly selected as a base meeting for GSoC this year.

I will still participate as mentor in Jenkins, and as org admin in Keptn and maybe FOSSi Foundation. Will try to submit my project ideas as pull requests tomorrow

1 Like

@basil @krisstern and all mentors - pls review and follow these steps for your project idea proposal Proposing new project ideas

Thank you,

Hi @martinda - have you considered proposing this idea and or maybe joining as org admin as well?

Sorry, I won’t participate this year.

No worries, thank you @martinda

Hi @alyssat I have submitted a PR regarding the Jenkinsfile Runner Action for GH Actions project idea. It has been approved and is pending to be merged. The PR is here: Update the GSoC 2022 project proposals by jmMeessen · Pull Request #4824 · jenkins-infra/ · GitHub.


Thank you so much @krisstern

1 Like

Hello @basil,

Since the end goal is to have a tool that automatically makes changes in a plugin’s codebase based on the factors mentioned by you, I have a small question about updating the plugin’s parent pom to the latest version.

I tried to update a plugin’s parent POM version and when I ran “mvn clean verify”, I observed the “Require Upper Bound Dependencies” error. @MarkEWaite helped me in rectifying the error by performing some step-by-step changes, and then we also “manually” suppressed the SpotBugs’ warnings by making some decisions.

Question: How do we automate this part where we have to manually suppress SpotBugs warnings?

This belongs in a separate discussion thread, but I will answer regardless.

Question: How do we automate this part where we have to manually suppress SpotBugs warnings?

Three possible solutions, in order from best to worst:

  • Adding the @SuppressFBWarnings annotation to the relevant method (through some Java source code manipulation tool, like whatever Refaster is using).
  • Adding the @SuppressFBWarnings annotation to the relevant class (through some Java source code manipulation tool, like whatever Refaster is using).
  • Disabling SpotBugs repository-wide by setting spotbugs.skip to true in pom.xml (through some XML source code manipulation tool, like whatever SortPom is using).
1 Like

Thank you so much for this Kris.

1 Like

Hi, may I ask where can I share a project idea that I want to do as a GSOC student? I want to be the student who implement the feature, not a mentor.
Thanks in advance!

Hi @Mostafa-wael,

Pls see Google Summer of Code. Information for GSoC Contributors, specifically under the section First begin a communication in Discourse for how you may propose your project idea as a GSoC contributor.


1 Like