Using moderne.io to Modernize Jenkins Plugins in an Industrial Way

Project goal: To find out the many ways moderne.io, an all-in-one automated code warehouse and remediation platform, can be used modernize Jenkins plugins in an industrial way, and implement the solutions by creating recipes and recipes of recipes.

Skills to study/improve: The Moderne platform, Jenkins plugin modernization, Automated code remediation

NOTE: This idea is published as a draft under active discussion, but it is confirmed in principle. It is FINE to apply to it. The scope and the suggested implementation may change significantly before the final version is published. Sections like quickstart guide and newbie-friendly issues may be also missing. As a contributor, you are welcome to request additional information and to join the discussions using channels linked on this page.

Details

Background

The Moderne platform is a tool for automated code remediation and is comprised of three components:

  1. Management console - organization views, recommendations, change campaigns, AI-assisted analysis, recipe building, recipe marketplace

  2. Code warehouse - aggregated, full-fidelity code data, horizontally scalable to orchestrate distributed operations

  3. Refactoring engine: - 100% accurate, format-preserving code remediation leveraging the Lossless Semantic Tree (LST)

Essentially, the goals would be to use moderne.io to:

  1. Make a nice recipe of recipes

  2. Create new recipes

in order to modernize existing Jenkins plugins in an industrial way, so that we can achieve better and more secure source code all the time.

Implementation

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

Quick Start

Use the "Contributing to Open Source" document and the "Modernizing Jenkins Plugins" video series to understand some of the transformations.

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.

Expected outcomes

New feature will be developed towards the end of the project.

Details to be clarified interactively, together with the mentors, during the Contributor Application drafting phase.

Potential Mentors

Project Links

Organization Links

> Go back to other GSoC 2024 project ideas