chore(docs): alpha-testnet versioning

[signorecello]

Aztec docs versioning

First we need to understand how docusaurus manages versions:

• There are two folders: versioned_docs and versioned_sidebars. These hold literal copies of the docs. So you may see a folder v0.83.0 that means docs as they were at version v0.83.0. They will not match the current versions in docs, and we can change them at any time (ex. to fix a typo that spans over multiple versions).
• There's a little file that governs which versions actually get into the built itself, called versions.json. It just holds an array of versions.
• When we cut a new version, docusaurus builds the website. Currently it will also expand all the custom #include_code and similar macros, basically making it a fully ready-to-go build. Then it moves it to the versioned_docs folder.

Our process

Our process uses the standard Docusaurus flow, but we follow some rules:

1. Always cut new versions - The idea is that whatever the release is, it will always build and cut a new version. For example 0.83.0 is a new version, 0.83.1, etc. All of them will pile up in versioned_docs, but because docusaurus only includes the ones in versions.json, it won't increase build times.
2. Include code at the tip - Docs must be in sync with the code. So if a new version is cut at the tip, all the #include_code macros should be resolved to the code at that point. This is why all the macros are expanded in versioned_docs.
3. Don't plan ahead - We may release 0.83.2 and then want to roll back to 0.81.1. We can't wait for a 0.82.3 release, but we also don't want to always deploy whatever is in master. So what we do is run a script setStables.ts just before building the docs, this will grab the latest info from github, and write to versions.json, so then docusaurus knows which versions we want.
4. Master always deploys - The above point means if there are changes to docs, they should be deployed on every merge to master and/or on manual workflow triggers. We want to be able to make changes to a previous version (ex. a typo) and see them live when the PR is merged.
5. Previews - Markdown behaves differently in different environments, and specially for big changes we may prefer to have a preview. Netlify provides this.
6. Release-please force-pushes last - If release-please cuts a new version of docs and then we add PRs to it, it would be publishing the version at the time the release-please PR was opened (at the previous version!). So what we want is release-please to always build the docs whenever it advances its pointer to the last included PR and then force-push.

In our case, we want docs to always show three kinds of versions:

• The latest release
• The latest alpha-testnet release
• The latest master

This all goes into the setStables script, which applies the filtering logic. On Noir it just grabs the last 2-3 versions, in our case it grabs the last one with and without alpha-testnet in its name. The version in master is "free", as docusaurus always deploys the "next" or "dev" version by default.

How

We just follow the tried and true process with Noir, which has been running for like a year now. Check the release-please PRs there to see it working.

On this PR you're looking at the following changes:

• Release-please has a new action that cuts a new version and force-pushes it
• Some visual changes to accomodate the dropdown
• The setStables and cut_version scripts that are basically copied from Noir
• The versions for 0.82.2 and 0.82.2-alpha-testnet

[AztecBot]

Docs Preview

You can check your preview here.

[signorecello]

chasing a moving target here tho 😄 (joking, this is the price of progress 💪 )