Create release branches as part of the release workflow

[sandhose]

The intended workflow is as follows:

• release-branch.yaml:
  • creates a new RC tag for the next pre-release
  • pushed to the main branch
  • and pushed to a release/vX.Y branch
  • creates a vX.Y branch in Localazy. Upload and download actions were adapted to use that branch
• release-bump.yaml bumps a version on a release branch
  • if it has RC set it will do a new RC
  • if not it will do a stable release (next patch version if we were not on an RC yet)
  • if it has Merge back set, it will open a PR release/vX.Y -> main
• the git tag creates the usual docker image + GitHub draft release through the build.yaml workflow

One flaw of this workflow, is that the docker latest tag is updated every time we publish a 'stable' release, so if we decide to bump on an older release branch, it will set that as the latest release tag

For future reference if we want to fix that

> git tag -l 'v*' | xargs npx semver --preid rc
0.0.0-test.0
0.0.0-test.1
0.1.0
0.2.0
0.3.0
0.4.0
0.4.1
0.5.0-rc.0
0.5.0-rc.1
0.5.0-rc.2
0.5.0
0.6.0
0.6.1
0.7.0
0.8.0-rc.0
0.8.0-rc.1
0.8.0
0.9.0-rc.0
0.9.0-rc.1
0.9.0
0.10.0-rc.0
0.10.0
0.11.0-rc.0
0.11.0
0.12.0-rc.0
0.12.0-rc.1
0.12.0

[cloudflare-workers-and-pages]

Deploying matrix-authentication-service-docs with    Cloudflare Pages

Latest commit:	381266a
Status:	✅  Deploy successful!
Preview URL:	https://9549d97e.matrix-authentication-service-docs.pages.dev
Branch Preview URL:	https://quenting-release-branches.matrix-authentication-service-docs.pages.dev

View logs

[reivilibre]

This looks good.

Just a perfectionist point (though maybe there's a worthwhile speedup in there).

Maybe also: would it be worth having a dev doc page on how to build a release, even just bullet points of 'go and run X workflow, then merge the PR, then do this...'?

[reivilibre]

I guess this is idiomatic for GHA but it feels suboptimal that we have to install Rust imperatively/slowly, particularly for just ... running cargo metadata.
When I used to self-host Drone/Woodpecker CI, this would have been done by running the command on a Rust container image that already had it installed.

Separately but also along the same lines: how intensive is cargo metadata — does it need to fetch all dependency crates? That would seem suboptimal just for reading a version.
Maybe there's a TOML version of jq that we could use to just pull it out of mas-cli/Cargo.toml? :-), or some toml2json | jq?

[sandhose]

That's fair, although the current release process took about 30s, including the rustup install, so I'm not too concerned about this slowing down the release :)

[reivilibre]

(ditto)