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.
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.
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.
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.
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
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).
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!