ci: update release workflow

[zepfred]

This PR updates the release workflow:

1. Deleted .github/workflows/release.yml — removed the old GitHub Actions release workflow.
2. Deleted jreleaser.yml (renamed to jreleaser-maven.yml, then removed along with jreleaser-jfrog.yml).
3. Added .github/scripts/change_versions.sh — new reusable script that updates the Maven project version.
4. Updated finish_release.yml — replaced inline mvn versions:set call with the new change_versions.sh script, and fixed a shell injection risk by passing ${{ github.ref }} through an env.

[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.

[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.

[Copilot]

Pull request overview

This PR updates the project’s release automation by removing the previously centralized release workflow/JReleaser configuration from this repository and tightening the remaining “finish release” steps by extracting version-updating logic into a dedicated script.

Changes:

• Removed jreleaser.yml and the Release workflow (.github/workflows/release.yml) from this repository.
• Updated .github/workflows/finish_release.yml to use a safer tag reference handoff and to call a shared version-change script.
• Added .github/scripts/change_versions.sh to centralize Maven/POM version updates used during the “finish release” process.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
jreleaser.yml	Removes repo-local JReleaser release configuration as part of moving release automation elsewhere.
.github/workflows/release.yml	Removes the old release entrypoint workflow from this repository.
.github/workflows/finish_release.yml	Adjusts finish-release behavior and tag ref handling while keeping branch update logic.
.github/scripts/change_versions.sh	Adds a reusable version-update script for release-finishing steps.

Comments suppressed due to low confidence (1)

.github/workflows/finish_release.yml:41

• The branch existence check uses grep -w $version where $version contains dots and is treated as a regular expression, which can match unintended branch names and cause the workflow to take the wrong path.

          tag="$TAG_REF"
          tag_version=${tag##*/}
          version=${tag_version%.*}
          version="${version:1}.x"
          echo $version

[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