Re-introduce staging into release process

[manovotn]

The Eclipse parent project, from which we inherit release configuration, has issued a new version that adds staging profile (and snapshot releases).

Parent was upgraded via - #945
The eclipse-ee4j README has a neat diagram showing what is configured and what profiles should be used.

We will need to tweak our release job which is here:

• Keep the classic straight up release process which is going to be used for pretty much all but final releases
  • Profile -Poss-release - we use that already but have slightly different maven goals specified
• Add staging release as a config option of this job
  • Profile -Pstage-release
• Clone and update the original stage-releasing job
  • Profile name is -Ppromote-stage and the required property with staged ID artifact is nexus.staging.repository
• [optional] Add configuration for snapshot releases?
  • Personally I don't think we'd use this as we can just issue any alpha/beta release when needed but it might be just me

NOTE: 5.0 has relocation artifacts that changed the group ID! This means they need to be released separately (as a separate release command) hence all changes we do for standard release need to be reflected in the setup for relocation artifacts as well. We currently release relocation artifacts within the same Jenkins job run.

Any takers? :-)

[manovotn]

CDI API in version 5.0.0.Alpha4 should now available along with its relocation artifacts.

I have managed to change the Jenkins release job to work with the stage/promote process for this repo and I have also created a Central Release job, which should be able to release the staged artifacts we need (as in, it already counts with the TCK repo).

I rewrote the job as well so that we avoid using release:perform - that nested maven build was mostly just causing headaches.

Technically, we retained the ability to release straight into Central too (no staging) - there is a boolean parameter for it.

To be considered and done:

• Staged artifacts should be dropped once promoted. However, as of now, I can still see them hanging in there
• At certain point I got into a state where I staged only classic artifacts and failed to stage relocation ones - I was able to just re-run it despite parts of it being present there already. I assume we can re-stage then but I found no documentation which would say anything about it either way 🤷
  • This would also mean we do not need a separate Jenkins job just to drop staging repo - which would be nice as I had hard time finding any info on how to set that up via the plugin.
• I still need to look into TCK job setup and do it in a similar way
• The direct release is untested at the moment, I only used the stage/promote path for now
• I didn't check the relocation artifacts were published correctly; I should and hopefully will remember to do that tomorrow :)
  • Checked in Central, these were published correctly

[manovotn]

A note for future self or any other readers.
Some of the questions I asked above will have their answers in this helpdesk thread - https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6890#note_6864508

Most notably:

• You can re-stage artifacts and it overrides
• You can do a staging repo drop but need to use rc-drop
• Staging repos are NOT automatically dropped after promote but it might be added in the future

[manovotn]

I have reworked the TCK release job similarly to the API one and after some required tweaks verified that it works by staging and promoting 5.0.0.Alpha3 (we have one job that can promote both repo based on execution parameters).

I did not try the non-stage release variant that both jobs retained - we can try that if we need another Alpha/Beta but it should be straightforward.

With that, I'm calling it done and closing this issue.

[manovotn]

I found out that the TCK release is wrong.
While the key files are there, not all of them made it.

I have not yet looked into why and how but the suit XML, coverage reports, sigtest files, audit files and possibly more didn't make it.
Here's Alpha 2 list of core-impl components - https://repo1.maven.org/maven2/jakarta/cdi/jakarta.cdi-tck-core-impl/5.0.0.Alpha2/
And here's Alpha3 - https://repo1.maven.org/maven2/jakarta/cdi/jakarta.cdi-tck-core-impl/5.0.0.Alpha3/

EDIT: Ok, to make matter more entertaining, the staging repo actually has all of these artifacts, they are just ignored during the promote process.

I am not sure what we can actually do in this regard.
And this is probably linked to staging workflow only, if we were to push directly to Central it would likely work...

EDIT2: I have asked on the Eclipse helpdesk issue mentioned earlier. Maybe someone with more Maven Release-fu knowledge can help me understand we this is something we can address :)

[manovotn]

FTR, yesterday I did another CDI API release to account for the merged changes (Alpha5) and that one I did as a direct release into Central to verify that capability still works.

I will probably do the similar for TCKs once we merge the PRs as that release should be complete (see the comment above) and will keep doing that until I get more information on how to promote custom artifacts.

As a side note - I am on track with Weld implementation for CDI 5 as well, there is a pending PR which should cover all that has been merged so far and pass all the TCKs.