Rejection of new hosting requests using the Gradle JPI plugin

[NotMyFault]

Hey,

I would like to let you know that the hosting team plans to reject new hosting requests using the Gradle JPI plugin. Existing plugins are unaffected by this change. The hosting team would then recommend to use maven as build tool.

There are several reasons why we would like to reject new hosting requests using the JPI plugin
(this is a non-exhaustive list of topics I am aware about, there are possibly more items to add by other people):

• No support for JEP-229
• No support for JEP-305
• Lacking end-user documentation on jenkins.io
• No support for publishing static analysis and coverage reports on ci.jenkins.io
• No support for building on ACI (Azure Container Instance) agents
• Suspect to produce invalid pom.xml files causing issues with third parties and the update center in the past

We want to provide people a good experience and access to all tools possible, when we host their plugins. Given, the JPI plugin is very limiting, and we see no ongoing efforts to support the same scope maven has, we would like to advise new hosting requestors to use maven.

Once all points above are addressed, we are happily looking into to accept new hosting requests using the JPI plugin again.

Taking the positive feedback on the mailing list into consideration, I would like to go ahead with this item soon.

~ Alex, for the hosting team

[timja]

cc @sghill @c00ler

[sghill]

@NotMyFault Thanks for letting me know. The most recent OSS plugin I started used maven as well to take advantage of all the great work the community has done here, so I definitely understand.

My priorities for maintaining this plugin are primarily Gradle compatibility, as I have several closed source plugins and we use Gradle internally. In this regard, the plugin is in great shape. We have 476 acceptance tests that can easily be run against any version of Gradle (including pre-releases) and any version of Java.

I don't intend to work on this in the near future, though I would support anyone else who wanted to. To that end, I will create issues for these and wrap them up into an "accept hosting requests" milestone.

I did want to outline what I thought would address these issues and ask a question to make sure I understand first though.

I believe these amount to configuring built-in features of Gradle:

No support for JEP-229
No support for JEP-305

These could be supported by adding the expected version format and creating/updating a shared library to publish.

No support for publishing static analysis and coverage reports on ci.jenkins.io

Spotbugs, pmd, checkstyle all have plugins that could be run through the shared library.

Suspect to produce invalid pom.xml files causing issues with third parties and the update center in the past

Is there a place I can read more about this? I'm not sure why it wouldn't work as-is. Gradle is able to bootstrap, resolve dependencies and build so long as java is present.

Suspect to produce invalid pom.xml files causing issues with third parties and the update center in the past

I believe this was fixed in v0.31.0 (released November 2019) as 792be79.

[NotMyFault]

Thanks for sharing your insights. We've disabled the Gradle checker from the hosting tool a few days ago.

[sghill]

I know it's rarely easy to end support for something, but I wanted to say I do appreciate the clear and thoughtful communication. Thanks for taking the time to create an issue here with links for more context @NotMyFault. Also thank you for the ping @timja.

I have defined a new milestone for hosting support with attached issues mentioned here. I have also updated the README with a warning near the top to give users more context. I believe that takes care of the action items here, so I'll close this one out.

[alextu]

@NotMyFault a new JPI plugin version was released by @sghill that brings building blocks for publishing incrementals and quality checks. That being said, afaiu it would require some glue in buildPluginWithGradle.groovy to support incrementals and report quality checks on https://ci.jenkins.io. Is it something you're willing to take on your side ?

[NotMyFault]

Thanks for the follow-up. I'm not interested in contributing to the Gradle parts of the pipeline library, but you are very welcome to propose any changes you believe are needed to the repository, to get it working.

[alextu]

Thanks, I've submitted some PRs to support quality checks and incrementals, waiting for your reviews 😄

[alextu]

Regarding

Lacking end-user documentation on jenkins.io

I think there are 3 use cases:

• publishing incrementals when building on jenkins, nothing to do except upgrading the JPI plugin, I can document this, but wonder where ?
• publishing incrementals when building "manually", this is documented in the JPI plugin readme
• publishing incrementals continuously as releases with Github actions, this is actually not supported by the current Github action for Gradle builds, see https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/run.sh). As a side note, I wonder why this wasn't handled by promoting artifacts from the incrementals repository to the releases repository (to avoid rebuilding).

[timja]

publishing incrementals when building on jenkins, nothing to do except upgrading the JPI plugin, I can document this, but wonder where ?

Probably a post on the developers mailing list / at least in release notes

publishing incrementals continuously as releases with Github actions, this is actually not supported by the current Github action for Gradle builds

once supported instructions should probably go on jenkins.io as maven ones are there