Add task to "Publish or Drop the Deployment"

[marcphilipp]

What feature do you want to see added?

When using USER_MANAGED as publishingType, it would be useful to have a second Gradle task available that calls the Publish or Drop the Deployment API. The task should have a --deployment-id parameter that expects the ID of a previous deployment (should be logged by the exising upload task). Similar to the existing publishing task, this task should wait for the deployment to reach the PUBLISHED state.

Context

The JUnit team uses this two-stage approach to validate the artifacts that are about to be published are consumable from Maven, Gradle, etc. by using the temporary staging repository. If that validation passes, we're promoting the deployment to Maven Central. Currently, we're using the JReleaser plugin to accomplish that which provides such a task (via the JRELEASER_MAVENCENTRAL_STAGE env var). However, this is the only bit we use from it and we'd like to replace it with a simpler alternative with fewer dependencies.

Upstream changes

None.

Are you interested in contributing this feature?

Yes, if this is something that you think should be part of the plugin.

[martinbonnin]

Hey 👋 Thanks for sending this!

I'm always a bit itchy with Gradle CLI arguments. They feels like something that belongs in a proper cli and not in a build system (because there are no real input tracking, can start in sub-millisecond, etc...).

On the other hand, I also get that adding a CLI install step is also cumbersome.

What if the deploymentId was output to build/nmcp/deployment.json (or something similar) and then there was a separate CLI to publish or drop the deployment?

nmcp publish build/nmcp/deployment.json
nmcp drop build/nmcp/deployment.json

Or is the CLI install step a no-go?

[marcphilipp]

In my case, the machine building the binaries is not the same as the one publishing it. Therefore, using a JSON file would make in unnecessarily complicated. I don't have a strong opinion on whether it should be a CLI or a Gradle task.

[marcphilipp]

Assuming there's no CLI, yet, would a PR adding a Gradle task be welcome?

[martinbonnin]

You're right, let's not complexify this too much. Let's do the path of least resistance. I think we need 2 tasks?

• ./gradlew nmcpPublishDeployment --deployment-id $DEPLOYMENT_ID: waits for the state to reach PUBLISHED (or FAILED), honours the configured timeouts?
• ./gradlew nmcpDropDeployment --deployment-id $DEPLOYMENT_ID: waits for the state to reach ?? (maybe doesn't need to wait at all if the API request is successful?)

If you're up for it, that'd be very welcome.

[marcphilipp]

I think we need 2 tasks?

I think publishing is the more important use case but we can certainly add two tasks.

I've opened a draft PR:

• Add nmcpPublishCentralPortalDeployment task #251