ci(release-automation): make release issuance atomic

[petermetz]

Depends on #1951

Description

As a maintainer I want to be able to issue releases without hassle so that I can spend more time doing other maintainer chores.

Currently we have scripts that automate the release issuance, but the way it works right now is that you run the script locally on your machine and then issue a PR with the administrative changes registering the release (like the version numbers being bumped in the package.json files, generating the CHANGELOG entries, etc).

The problem with this is that you tag your release commit when you make it and at the same time the npm packages get automatically published as well. So lots of automation and convenience already, but there's a concurrency issue at play which already manifested itself with our 0.2.0 release: If someone gets between your release PR and your release commit, then your tag will actually diverge, which is not a huge issue, but it could become confusing/annoying/even problematic once we get to GA and start doing hotfixes, backports on older release branches regularly (an unfortunate chore of mature software maintenance).

So, I had this idea (that I actually just stole from Besu, while I was browsing their CI code for something totally unrelated) that what we need is a separate github action (workflow yaml file in the .github directory) that will run only on branches matching the pattern of release-* and this workflow will run the publish script that uploads the package contents to npm (and later on all the other things that we want to publish such as Java jars to BinTray/Maven Central for the Java bindings to the Cactus API).
With this change, the release workflow would become this:

1. Run release script locally on your machine, send a PR
2. Have everyone agree on the release (e.g. approval)
3. Merge the PR
4. Tag the commit you just merged
5. Create a branch called release-$SEMANTIC_VERSION
6. Push the branch to the upstream (e.g. Hyperledger/Cactus)
7. Sit back and watch the CI publish your artifacts (because it got triggered by the branch name matching the pattern mentioned above).

Acceptance Criteria

1. Possibility of diverging the release tag from the main branch is eliminated
2. npm packages are automatically published and before the container images are published (sequential order for them must be guaranteed)

cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo @petermetz @arnab-roy @jagpreetsinghsasan

[petermetz]

@ryjones I found this GH app called "MergeFreeze" which is meant to help out with situations like ours where PRs that are about issuing releases need to halt all other PRs until they are merged to keep the generated change logs and build artifacts consistent.
Any chance that you could enable it for the HL GH org? It is free for open source projects so I'm hoping this is not something Hyperledger would get charged for at all (entirely different conversation if that's not the case though).

MergeFreeze: https://github.com/marketplace/merge-freeze/plan/MDIyOk1hcmtldHBsYWNlTGlzdGluZ1BsYW4yMjAy#pricing-and-setup

[ryjones]

@petermetz I've installed it, but I'm not sure what more I need to do. If it needs more config, let me know?

[petermetz]

@petermetz I've installed it, but I'm not sure what more I need to do. If it needs more config, let me know?

@ryjones It worked! Now I have a tool to keep the release issuance atomic, happy days!

[petermetz]

The last part for this seems to be to have npm packages auto-published BEFORE the container images get auto published (right now it's the other way around and it breaks the container image publishing given that the containers need the latest npm packages already published on the registry before they can be built)

Update 1: With the addition of ncc to the build (a bundler similar to webpack but I could actually get it to work for the back-end packages) we don't need the npm packages to be published prior to the release issuance to npm.

[github-actions]

This PR/issue depends on:

• hyperledger/cacti#1951
  By Dependent Issues (🤖). Happy coding!

[petermetz]

Update 2: The npm publishing now works from the CI, the last thing remaining is that the GitHub token is not getting recognized somehow in the publishing job and that fails some of the weaver packages. Here's the complete log of the job:

Uploading 2024-07-04T15-18-17-cacti-ci-npm-publish-crash.log…

[petermetz]

Re-opening because there was a small bug in the publish workflow where I accidentally mixed up the ghcr and npm tokens in the environment variable declarations.