alyssat GSoC Mentors

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,
alyssa

1 reply

halkeye Leader

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.

1 reply

martinda

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.

2 replies

alyssat GSoC Mentors

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.

halkeye Leader

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

MarkEWaite Jenkins Governance Board

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.

basil Jenkins Governance Board

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.

1 reply

oleg-nenashev Earliest Adopters

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

alyssat GSoC Mentors

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

Thank you,
alyssa

alyssat GSoC Mentors

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

1 reply

martinda

Sorry, I won’t participate this year.

1 reply

alyssat GSoC Mentors

No worries, thank you @martinda

krisstern GSoC Mentors

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/jenkins.io · GitHub.

2 replies

alyssat GSoC Mentors

Thank you so much @krisstern

dheerajodha Earliest Adopters

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?

1 reply

basil Jenkins Governance Board

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

alyssat GSoC Mentors

Thank you so much for this Kris.

Mostafa-wael

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!

1 reply

alyssat GSoC Mentors

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.

Thanks,
alyssa

krisstern GSoC Mentors

Hi everyone,

I have been thinking if there is a demand I could volunteer to mentor one additional project, for example the Automatic Git Cache Maintenance project idea. I think I will have the time capacity based on my current situation.

1 reply

MarkEWaite Jenkins Governance Board

That would be great @krisstern ! @rishabhBudhouliya has also agreed to mentor that project idea.

I’ll add your name and his name to the list of possible mentors and will update the status of the project idea of www.jenkins.io.

1 reply

krisstern GSoC Mentors

Thanks @MarkEWaite! Appreciate your updating the GSoC docs on GitHub for the project as well

olamy

Project idea: implements CD using Jenkins rather than an external concurrent tool…

2 replies

Jmm GSoC Mentors

Although a HUGE topic, it is a very interesting and useful project idea.
I believe it is worth giving this idea some substance (and describe what could be done by a GSoC contributor). Do you have some description/ideas you could throw on a piece of paper and share with us ?
We could then pair together to give it adequate substance so that we can add it to the GSoC list.

WDYT?

olamy

there are already some specifications here in a JEP jep/jep/221 at master · jenkinsci/jep · GitHub.
it doesn’t look to be so complicated to implement.
But probably the JEP need to be refreshed for some parts or rewrite.
And requires some coordination with Jenkins security and Jenkins Infra team so can be definitely a good exercise for some intern project to have a broader view of what an IT project is.

jglick

Basically an alternative to the infra side of JEP-229. Would require setting up a new Jenkins service dedicated to this task with a completely different authorization model pulled from GitHub permissions, changing the RPU processor to push Artifactory bot credentials to that rather than GitHub secrets, and then also securely managing GitHub tokens (perhaps by implementing a GitHub App) to run Release Drafter in CLI mode and edit tags & releases, provide some way of automatically provisioning deployment jobs, and come up with a plan for migrating dozens of existing repositories to the new system. Not at all straightforward (subtle security issues), and certainly not something a student can work on independently—would require close collaboration with someone on the infra team who would need to set aside significant time for this. For plugin developers there would not be much benefit, though we could offer a nicer UX for browsing the occasional deployment failure. To make this not be a pile of one-off hacks I think you would need to overhaul and significantly expand the GitHub Authentication plugin in addition to the jenkins.io-specific infrastructure work.

1 reply

olamy

That’s a very interesting amount of valuable informations.
Thanks for that!