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

[Build] Clean-up and update maven deployment configuration #2730

Merged

Conversation

HannesWell
Copy link
Member

Move the Maven plugin configuration to the eclipse-platform-parent/pom.xml and update the configured plugins.

<nexusUrl>https://oss.sonatype.org/service/local/staging/deploy/maven2/</nexusUrl>
<!-- The server "id" element from settings to use authentication from -->
<serverId>ossrh</serverId>
</configuration>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if should set the skipStagingRepositoryClose property here as described in
https://github.com/sonatype/nexus-maven-plugins/blob/f5ba90d339064c4981716a98e4afa6a76bc3ff2e/staging/maven-plugin/README.md#plugin-flags

But I also wonder in general why it has worked until now without it being set while each file project is deployed in an individual Maven build.
From #2718 (comment), @elsazac can you tell me where I can find the staging repository in case I ran a release publication to a staging repo as a test?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I publish the artefacts for a release, I first run the CBIaggregator Job, which in turn triggers the PDE, JDT, and Platform. After these jobs successfully complete, the generated repositories can be seen under the Staging Repositories tab in the Build Promotion section in Maven central repository.

Screenshot 2025-01-06 at 1 29 06 PM

I’m trying to get the full context of the change and reviewing the details to understand it better. I’m not sure if this is exactly what you were asking me to clarify, so please let me know if there’s anything else you’d like me to address.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem as I understand is is that what you see at https://oss.sonatype.org/#stagingProfiles depends on your credentials/access, so when I log in there I can see EMF's staging content.

image

But we/I don't see the jdt/pde/platform repositories.

We believe that some -release builds have been done that have populated those 3 repositories but we can't see that and can't help manage that. Probably best that content be dropped, but it seems maybe only you can do that.


Note that all the separate jobs have been combined into this single pipeline job:

https://ci.eclipse.org/releng/view/Publish%20to%20Maven/job/Releng/job/PublishToMaven/

All the other jobs will be deleted...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem as I understand is is that what you see at https://oss.sonatype.org/#stagingProfiles depends on your credentials/access, so when I log in there I can see EMF's staging content.

But we/I don't see the jdt/pde/platform repositories.

Even for me, as I have access to the Maven Central site, I can see the three repositories in the staging area only, once the Jenkins jobs are successfully completed running with -release parameter.

Screenshot 2025-01-06 at 1 57 49 PM

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you Elsa for your help. That's interesting because as explained in #2718 (comment), I actually expected that (accidentally) some staging repositories were created due to the old configuration of the parameter default in combination with the cron trigger.
E.g. https://ci.eclipse.org/releng/job/CBIaggregator/1281/ ran with parameter -release and triggered https://ci.eclipse.org/releng/job/RepositoryValidator/1020/, which eventually triggered

and that happened multiple times.
And the changes you are applying for releases to the SDK4Mvn.aggr, e.g. in #2613, as far as I understand them only change the source.

Therefore I still would expect that the Jenkins job executions listed above should have created a staging repo.

But maybe I have to run the job with -release option and more print-out to see where the artifacts are actually going to.

Copy link
Member

@elsazac elsazac Jan 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually I do close all the repositories and then release. while releasing, I make sure to check the Automatically Drop checkbox;

In this case, Do you want me to just only drop ? and not close or release it?

Screenshot 2025-01-06 at 5 54 43 PM

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop is the correct thing here if it was only for testing purpose.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, Do you want me to just only drop ? and not close or release it?

Yes please just drop and do not close or release!

But before doing it, it would be nice if you could check if these staging repos can be accessed publicly or can be made publicly accessible?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a built-in option as such to make staging repositories in Maven Central publicly available.

These are the only options that's seen available for any work related to the staging repositories.

Screenshot 2025-01-06 at 6 13 33 PM

Is there anything else you’d like me to check before I proceed with the drop?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there anything else you’d like me to check before I proceed with the drop?

No that's fine. Thank you for your help.
Please proceed with dropping these staging repos.

I have a few more changes in this area in the pipeline and once they are all done, I plan to run another release build for testing on a clean repo. It would be great if you could drop/discard that then as well, but I'll ping you when this is necessary.

@HannesWell HannesWell force-pushed the maven-publication-config branch 2 times, most recently from 2ac5e3e to 5de4950 Compare January 6, 2025 20:42
Move the configuration of the maven-gpg-plugin into the
eclipse-platform-parent/pom.xml and update it to the latest version.

Remove the configuration of the 'nexus-staging-maven-plugin' as it is
effectively unused because the 'gpg:sign-and-deploy-file' deploys
directly without using the 'deploy' phase that's intercepted by the
staging-plugin. Removing it saves additional configuration that
potentially has to be maintained and is not easy to understand.
And because the 'gpg:sign-and-deploy-file' goal is configured directly
in the job as well, the 'ossrh' repository in the distributionManagement
is also effectively unused and can be dropped too.
This avoids the need to specify and maintain the id of the key to use.
Because the keyring only includes one key, there is no need to specify
that one explicitly as it's then the first one and therefore chosen by
default.
@HannesWell HannesWell force-pushed the maven-publication-config branch from 5de4950 to b2850fc Compare January 6, 2025 21:29
@HannesWell
Copy link
Member Author

After some more testing I'm now convinced that configuring nexus-staging-maven-plugin is not necessary because it's effectively unused as the gpg:sign-and-deploy-file performs the deployment directly. For the same reason specifying the ossrh-repository in the distributionManagement is not necessary.

Additionally it's also not necessary to specify the id of the gpg-key used for signing as there is only one key in the keyring anyways and it's therefore selected by default. I have simplified the configuration to remove that unnecessary explicitness as well.

All my extensive testing with these changes was successful and therefore I consider this ready for submission.

Thanks to everyone who helped with this.

@HannesWell HannesWell merged commit 4d6c9b3 into eclipse-platform:master Jan 6, 2025
2 of 4 checks passed
@HannesWell HannesWell deleted the maven-publication-config branch January 6, 2025 21:34
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

Successfully merging this pull request may close these issues.

4 participants