Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standalone close and release #215

Open
matejdro opened this issue Apr 14, 2023 · 3 comments
Open

Standalone close and release #215

matejdro opened this issue Apr 14, 2023 · 3 comments

Comments

@matejdro
Copy link

Due to #75, we are setting up publishing manually and then use old https://github.com/Codearte/gradle-nexus-staging-plugin plugin to just close and release.

We want to migrate to this new plugin, but from what I can see, this plugin cannot perform standalone close and release? I've tried using it and I'm getting "No staging repository with name sonatype created" error, presumably because I did not use the plugin to publish and thus staging repository is named something else than "sonatype".

Is there a way to get this plugin to detect the name of the staging repository, rather than just using hardcoded "sonatype", which would allow using close release in a standalone fashion?

@szpak
Copy link
Contributor

szpak commented Apr 14, 2023

We want to migrate to this new plugin, but from what I can see, this plugin cannot perform standalone close and release?

Could you elaborate more? "It" should be possible, but I'm not sure what you exactly mean.

presumably because I did not use the plugin to publish and thus staging repository is named something else than "sonatype".

"sonatype" is rather a part of configuration which indicates that you name the Nexus server you use "sonatype" (which is a good default name for Sonatype Nexus for Open Source Software).

Is this project publicly available? If you, please link to the CI build with the aforementioned error, preferably called with the --info switch (just for publishing, building can be called earlier without "info"). It would be much easier to find a configuration problem.

@matejdro
Copy link
Author

Here is the configuration that works with the old gradle-nexus-staging plugin: https://github.com/inovait/kotlinova/blob/ce0efdcdbadb4fee7aa96cc24db17142b8e04798/build.gradle.kts#L26

And here is my attempt to use new publish-plugin:
https://github.com/inovait/kotlinova/blob/9cbf41ea426216430d90eedc400cb062a3088359/build.gradle.kts#L28

which failed with the "No staging repository with name sonatype created":

https://github.com/inovait/kotlinova/actions/runs/4696563095/jobs/8326774433#step:20:55

(I can do it with the info switch a bit later, if necessary).

@szpak
Copy link
Contributor

szpak commented Apr 18, 2023

Thanks, now it is clear.

The main advantage of the new plugin GNPP is combining the functionality of my old plugin - GNSP and Marc's old plugin NPP. Thanks to that you already publish to the explicitly created staging repository, so you are sure what to close (including a possibility to ignore "old" open staging repositories).

It's a recommended way and if you don't use it (e.g. due to some problems with the Android project), I would recommend to stick with the old plugin (unless there are any Gradle 7 or 8 compatibility issues). There is a chance to have the support for monorepos (or more broadly to have a possibility to point the module which should be treated as a root module/project) will be implemented one day.

If you have any other strong reason to remove the old plugin from your project, please let me know. With some hacks there is a chance to be able to leverage the new findStagingRepository to simulate the old heuristic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants