chore: update release workflow

[zepfred]

This PR updates the release workflow:

1. Includes two JReleaser configurations, one to deploy to Maven and another to JFrog.
2. When deploying to JFrog, an artifact file is generated to be reused later for deployment to Maven.

[triceo]

My recommendation:

• Do not move away from the YAMLs. The XML configuration is both harder to read and harder to write; XML is just not a good format for this, IMO.
• I'd prefer if the configs lived in the enterprise repository. Surely JReleaser can accept the config file location via a system property.

[zepfred]

My recommendation:

• Do not move away from the YAMLs. The XML configuration is both harder to read and harder to write; XML is just not a good format for this, IMO.
• I'd prefer if the configs lived in the enterprise repository. Surely JReleaser can accept the config file location via a system property.

There is one issue with the YAML files. I couldn't find a way to switch the working-dir when updating multiple projects. For different config files, you can specify a configuration file argument in the JReleaser action indeed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[triceo]

If at all possible, I want everything related to a release located in Enterprise. I have a good reason for it - our releases require secrets, and the community repository allows untrusted forks. This is ultimately a bad situation, and causes a lot of compromises in the CI, and constant worries if the mitigations are enough or if we're still at risk of leaking anything.

Another reason is that our release process is nobody's business - people needn't know anything about JFrog, or the two-step process. By exposing this information here, you are giving adversaries clues for possible attacks.

I think the following should happen:

• All YAMLs are in Enterprise repo.
• All workflows are in Enterprise repo.
• No release-related configuration exists in the Community repo.

This is perfectly achievable. You do not need to run JReleaser as a Maven plugin. You can run JReleaser as a command-line app - just like we did until now. This will allow you to centralize all config.

[rsynek]

@triceo me and @zepfred agreed to split the work into two parts:

1. finish the 2-phase release with reusing the same binaries
2. move everything to the enterprise repo

Is it ok to merge it the current way, try the release, and then finish 2, or do you prefer solving 2 before merging anything?

[triceo]

Personally, I see doing a release with something that will never be used again as a waste of time. But if you insist, I won't stop you.

[rsynek]

Thanks @zepfred ; I left there some comments and questions. If I understood correctly we push the archive with binaries to the github repository, I think we shouldn't. More details inline.

[rsynek]

Why do we need to delete a tag? Is that in case we are repeating a release of the same version? Can someone already depend on it?

[triceo]

The tag needs to remain; if we've built something and published it, the tag must never go away.

I'm assuming this exists in case we ever need to re-run CI perhaps due to a later failure? The better solution here is to just fail and delete the tag manually; tags in general should not be deleted. (Unlike branches.)

[rsynek]

Is this the archive with all the JAR files? If so, why do we push it to the tag? Binaries usually don't belong to SCM. Why not pushing it to jFrog?

[rsynek]

Here we are removing the archive, previously added to the git repository. This commit will be visible in the commit history. Even if we remove it, it will stay a part of the git repository's history and as such will be transferred every time the repository is cloned.

[triceo]

Yes, this will quickly make the repo blow up in size.