Move to CI-based release process

[trixter-osec]

Updates the existing release process to the proposed release process that is done fully in CI. In practice, the release process now consists of the following steps:

• Creating a branch with bumped versions using the existing bump-version.sh script
• Creating a pull request to master with those changes. This triggers dry-run of release process (or as close to it as we can be) to confirm that everything builds and is publishable
• The PR is merged, and a signed tag for that commit is created with release manager's GPG key to trigger the CI release process
• CI builds all npmjs and crates.io packages. It also builds the Docker image, the CLI binaries, releases the npmjs package with the CLI binaries, and creates a GitHub release with the binaries as well. Build attestation is used everywhere where possible

My understanding is that the typedocs are handled automatically by Vercel on merge to master, so it has been untouched in this PR, though let me know if this is not the case.

This has been tested against monkey-patched version pointing at my own packages for testing this with a subset of the packages, and hopefully the PR-specific release dry-run will catch any issues in advance as well. The verify-tag job has been verified with 1) non-signed tag (doesn't pass), 2) signed tag not belonging to any specific account (doesn't pass), 3) signed tag belonging to a release manager's account (passes).

The diff also contains repository.url in package.json being renamed, which is needed for npmjs build attestation to pass as it verifies that the repository URL matches the CI's repository.

Manual changes required before merging this PR

• Create a new environment named release
  • Setup variable DOCKERHUB_USERNAME and secret DOCKERHUB_TOKEN for solanafoundation/anchor (unfortunately, Dockerhub does not allow OIDC)
  • Setup RELEASE_MANAGERS variable, which is comma separated list of GitHub usernames that are allowed to push releases. This is used to pull their GitHub GPG key and verify that the tag is signed with their key before proceeding with the release process.
• Create a GitHub team in the organization, e.g. anchor-release-managers with all of the release managers in it
• In the repository settings, create the following rulesets:
  • New tag ruleset: Only release managers can create tags, with Restrict creations for all tags. The anchor-release-managers team should be added to the bypass list.
  • New tag ruleset: Restrict tag management, with Restrict updates, Restrict deletions, Block force pushes for all tags.
• Each release manager should have a GPG key configured in their GitHub account, preferably stored on e.g. Yubikey.
• For the following npmjs packages, add a trusted publisher with this repository, workflow name of release.yaml, and environment name of release:
  • @anchor-lang/borsh
  • @anchor-lang/spl-token
  • @anchor-lang/core
  • @anchor-lang/errors
  • @anchor-lang/spl-associated-token (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-binary-option (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-binary-oracle-pair (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-feature-proposal (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-governance (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-memo (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-name-service (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-record (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-stake-pool (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-stateless-asks (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-token-lending (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
  • @anchor-lang/spl-token-swap (this is not published though, if the plan is to keep publishing it an empty repository could be published to claim the name and setup trusted publishing)
• For the following crates.io crates, add a trusted publisher with this repository, workflow name of release.yaml, and environment name of release:
  • anchor-syn
  • anchor-spl
  • anchor-lang
  • anchor-derive-space
  • anchor-derive-serde
  • anchor-derive-accounts
  • anchor-client
  • anchor-cli
  • anchor-attribute-state
  • anchor-attribute-program
  • anchor-attribute-event
  • anchor-attribute-error
  • anchor-attribute-constant
  • anchor-attribute-account
  • anchor-attribute-access-control

Eventually, we would also want to restrict Publishing access in npmjs to Require two-factor authentication and disallow tokens (recommended) and Require trusted publishing for all new versions in crates.io, though for now this is not strictly necessary as we want to confirm the release process works before that.

[vercel]

@trixter-osec is attempting to deploy a commit to the Solana Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[jamie-osec]

Maybe we can move the logic of publishing into shared reusable workflows (.github/actions) to avoid some duplication and make sure our logic is in sync?

[trixter-osec]

Maybe we can move the logic of publishing into shared reusable workflows (.github/actions) to avoid some duplication and make sure our logic is in sync?

I'll play around and see what I can come up with, though the two release workflows being separate is mostly intended decision to be explicitly clear what happens during the release process. Although on a high level the process is similar between the two workflows, there's some minor differences (e.g. cargo build in dry-run compared to cargo publish) which would make it harder to follow and maintain.

[jamie-osec]

Yeah, I was imagining something like

if ${WORKFLOW_DRY_RUN}; then
  cargo build
else
  cargo publish
fi

etc to make it clear which steps are the ones that are being swapped out.

[jamie-osec]

Hmm, I think we probably want to publish this with the rest as it has historically followed the versioning scheme

We actually don't use crates.io for avm