Add manual release CI workflow (release.yaml)

[delthas]

Summary

Arsenal has no release workflow, unlike cloudserver, vault2, and backbeat, which each ship a workflow_dispatch release pipeline. Today arsenal releases are cut by hand via gh release create <version> --generate-notes.

This adds .github/workflows/release.yaml, triggered manually (workflow_dispatch), that:

• Reads the version from package.json (no manual tag input), so the released tag can never drift from what consumers pin (git+https://github.com/scality/arsenal#<tag>).
• Fails loudly if a release for that version already exists, guarding against accidental re-runs (softprops/action-gh-release otherwise updates an existing release silently).
• Creates the GitHub release + tag with auto-generated notes (generate_release_notes: true), targeting the dispatched commit.

Arsenal is a library (private: true, no Docker image), so the workflow reduces to the GitHub-release step only — no Docker/oras steps. Build artifacts continue to be published by the existing per-push compile job in tests.yaml. The release name is kept as the bare version (e.g. 8.5.1) to match arsenal's existing release history.

Issue: ARSN-604

[bert-e]

Hello delthas,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options

name	description	privileged	authored
/after_pull_request	Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval	Bypass the pull request author's approval	⭐
/bypass_build_status	Bypass the build and test status	⭐
/bypass_commit_size	Bypass the check on the size of the changeset TBA	⭐
/bypass_incompatible_branch	Bypass the check on the source branch prefix	⭐
/bypass_jira_check	Bypass the Jira issue check	⭐
/bypass_peer_approval	Bypass the pull request peers' approval	⭐
/bypass_leader_approval	Bypass the pull request leaders' approval	⭐
/approve	Instruct Bert-E that the author has approved the pull request.		✍️
/create_pull_requests	Allow the creation of integration pull requests.
/create_integration_branches	Allow the creation of integration branches.
/no_octopus	Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity	Change review acceptance criteria from one reviewer at least to all reviewers
/wait	Instruct Bert-E not to run until further notice.

Available commands

name	description	privileged
/help	Print Bert-E's manual in the pull request.
/status	Print Bert-E's current status in the pull request TBA
/clear	Remove all comments from Bert-E from the history TBA
/retry	Re-start a fresh build TBA
/build	Re-start a fresh build TBA
/force_reset	Delete integration branches & pull requests, and restart merge process from the beginning.
/reset	Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

[bert-e]

Request integration branches

Waiting for integration branch creation to be requested by the user.

To request integration branches, please comment on this pull request with the following command:

/create_integration_branches

Alternatively, the /approve and /create_pull_requests commands will automatically
create the integration branches.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.56%. Comparing base (7fd2be6) to head (3bd36fb).
⚠️ Report is 4 commits behind head on development/8.3.

Additional details and impacted files

@@                 Coverage Diff                 @@
##           development/8.3    #2656      +/-   ##
===================================================
+ Coverage            73.54%   73.56%   +0.01%     
===================================================
  Files                  222      222              
  Lines                18188    18188              
  Branches              3786     3786              
===================================================
+ Hits                 13377    13380       +3     
+ Misses                4806     4803       -3     
  Partials                 5        5              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[francoisferrand]

As logic is added to release workflow, bugs are also added : which is esp. critical for releases, which are only used seldom and especially when we need (urgently) a release... Thus (non-trivial) release workflow should be tested, as we do for exemple in Zenko

[maeldonn]

Need a test

[delthas]

Added some tests, inspired by Zenko.

[maeldonn]

Do we need a separate package? Root already has jest/ts-jest/typescript, so
@kie/act-js and @kie/mock-github could just be root devDeps. Avoids a second
yarn.lock to maintain. What's the reasoning?

[francoisferrand]

Suggested change

	uses: actions/setup-node@v4
	uses: actions/setup-node@v6

please check all actions, you are using outdated ones...

[francoisferrand]

there is also q/*/** to ignore : otherwise it will run twice on Bert-e's queue, since there are 2 branches : q/ and q//

[francoisferrand]

best to run on everything IMHO

• you never know if the workflow may depend on what's in the repo
• cheap anyway
• best to run periodically to find out before it breaks

[francoisferrand]

do we need a separate workflow file?
best to keep in same workflow as other test/premerge, like in other repos

[francoisferrand]

seems to do more than setup "repo" : it also setups act

[francoisferrand]

we need the GitHub variable for asynchronous cleanup in afterEach (unless we can register a cleanup step dynamically) ; but not the case for act : could we return it instead of relying on global variable?