ci: Add reusable workspace release workflow

[huitseeker]

This adds a shared workflow for Rust workspace releases.

Callers must pass the path to their MSRV check script. The workflow runs MSRV checks, semver checks, and then the release flow.

Dry-run treats semver regressions as failures. Publish reports them as warnings but still publishes.

Usage PR at 0xMiden/crypto#938

Pinned the shared workspace release workflow’s third-party actions to commit SHAs and disabled checkout credential persistence where no push access is needed.

[mmagician]

note to self: the job in the protocol repo uses slightly different inputs, though the underlying logic seems the same

[mmagician]

shouldn't this default to the latest toolchain (see 0xMiden/protocol#2729)?

[huitseeker]

I'm relying on the invariant that the repo should be using the default toolchain already.

[mmagician]

right, so in that case we shouldn't need these extra couple of steps to figure out the MSVR toolchain and to install it - or am I missing something?

[huitseeker]

Let me rephrase: this is an optional parameter, that's intended to not be provided in most case, and in this not-provided (default) case resolves to the repo's toolchain file.

This is just an override: in the case the MSRV check requires something else, they have access to a possible override. This is used in the consumer PR opened against crypto, linked in the PR description.

[mmagician]

I'm not sure I follow why there are two jobs "with" and "without" the environment. It seems that we're always going to default to the one with environment if we want to publish?

[huitseeker]

Yes, publish should always go through the job with the environment.

The split is there because environment is a job-level key, and with jobs.<id>.uses the caller cannot set it conditionally on the reusable job. So this keeps dry-run env-free, while publish can still attach the protected environment.

[mmagician]

So this keeps dry-run env-free

Would bad things happen if dry-run gets an environment as well?

[huitseeker]

Privilege escalation, if any consumer repo of this reusable workflow decides to use protection rules to manage the publication environment:
https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments
(or, of course, prevention from using protection rules in this privileged environment)

Basically, publish needs a secret which dry-run doesn't, and the best security practice is to tie this secret to that environment. (zizmor has a dedicated warning: https://docs.zizmor.sh/audits/#secrets-outside-env)