Implement GitHub action

[jonesbusy]

What feature do you want to see added?

• action can be added on same repo and uses same version scheme
• java based temurin 17
• download jar via java
• dry-run option as input
• recipe as input
• GH_TOKEN as auth (API and git)
• against current repo (--plugin-path option ? Or do we need and option to run on current repo and not create fork ?
• test against one plugin

Probably very similar to

https://github.com/jreleaser/release-action

Upstream changes

See if we need an option to apply changes on current repo and not perform forking

Are you interested in contributing this feature?

No response

[morishima-senpai]

Hi, I would like to work on this issue:)

[nagu165]

Hello sir,
Are there any plugins that won't support temurin 21 yet or we can update to using 21 as it is also a LTS version?

Thank you.

[jonesbusy]

Many outdated plugin are not supporting yet Java 17 or 21. But I think the use case here is more about applying latest archetype changes on plugins. So I would expect the action/workflow to be installed on only active plugin.

The minimum Java version for Jenkins is 11 and 17 for recent LTS version.

So I would for for Java 17 to run plugin-modernizer action

[gounthar]

@nagu165 : I think the question is not whether plugins will support Java 21 or not, but let me clarify a few things first. Many plugins won’t support Temurin 21 yet; we’re not ready. Jenkins core has been supporting Java 21 for a while now, and we started a campaign last year to upgrade the most installed plugins to Java 21. However, there are still many plugins that aren’t ready for Java 21, which is why we're focusing on getting them to work with Java 17 first.

Our goal in addressing this issue is to create a GitHub Action that would launch the modernizer tool. Then, the infra team could add this GitHub Action to existing plugins by default, or we could propose it through a PR to encourage maintainers to add this GitHub Action.

[nagu165]

Many outdated plugin are not supporting yet Java 17 or 21. But I think the use case here is more about applying latest archetype changes on plugins. So I would expect the action/workflow to be installed on only active plugin.

The minimum Java version for Jenkins is 11 and 17 for recent LTS version.

So I would for for Java 17 to run plugin-modernizer action

Ok sir, Understood.

[nagu165]

@nagu165 : I think the question is not whether plugins will support Java 21 or not, but let me clarify a few things first. Many plugins won’t support Temurin 21 yet; we’re not ready. Jenkins core has been supporting Java 21 for a while now, and we started a campaign last year to upgrade the most installed plugins to Java 21. However, there are still many plugins that aren’t ready for Java 21, which is why we're focusing on getting them to work with Java 17 first.

Our goal in addressing this issue is to create a GitHub Action that would launch the modernizer tool. Then, the infra team could add this GitHub Action to existing plugins by default, or we could propose it through a PR to encourage maintainers to add this GitHub Action.

Yes sir, I understand the context now.
Thank you for the inputs

[jonesbusy]

@nagu165 : I think the question is not whether plugins will support Java 21 or not, but let me clarify a few things first. Many plugins won’t support Temurin 21 yet; we’re not ready. Jenkins core has been supporting Java 21 for a while now, and we started a campaign last year to upgrade the most installed plugins to Java 21. However, there are still many plugins that aren’t ready for Java 21, which is why we're focusing on getting them to work with Java 17 first.

Our goal in addressing this issue is to create a GitHub Action that would launch the modernizer tool. Then, the infra team could add this GitHub Action to existing plugins by default, or we could propose it through a PR to encourage maintainers to add this GitHub Action.

Thanks for adding more context than me ;)