DRAFT: automate release workflow

[frenchi]

Draft PR to demo the github action based release workflow. Will tidy up comments & commits before opening, but I'll pause here for feedback.

Benefits:

Benefits over the current manual release workflow:

• attests SLSA build environment provenance, so consumers can validate releases e.g. gh release verify v0.5.0 -R modelcontextprotocol/go-sdk
• SBOM generation,
• (future) keyless signing of build provenance & assets so consumers can validate artifacts and lineage.
• Multi‑party approvals: Gate releases behind Environments with required reviewers
• Transparency & audit trail: CI logs, signed tag verification (“who cut this”), provenance attestations, and attached SBOMs make releases inspectable and defensible.
• Speed & reliability: Tag push triggers a fully automated release (source archives + SBOM + notes), less room for human error.

Demo

This release was cut automatically: https://github.com/frenchi/go-sdk/releases/tag/v0.5.4 via this workflow run: https://github.com/frenchi/go-sdk/actions/runs/17816393139

With approval gating: pre-approval approved

TODO:

• if the dependency cost is worth it, use sigstore for signing of source/sbom, to be uploaded alongside releases,
• Enable Immutable Releases
• Multi-party approval is possible via:
  • Github Repo Settings
  • -> Environments
  • -> release
  • -> Deployment protection rules
  • -> Required reviewers

[findleyr]

@rolandshoemaker I think you're familiar with this type of workflow. Can you advise on whether we should be adopting this post-release SLSA attestation?

[rolandshoemaker]

I've not followed along super closely with what the SOTA for source distribution provenance attestations are, but my understanding is that SLSA is almost entirely focused on attestations for build artifacts. What the build artifact for source distribution are is somewhat confusing.

It seems like in this draft, the artifact we are attesting is a SBOM document that contains a number of things, namely the dependencies (this seems vaguely redundant, since it ends up reiterating the contents of the go.mod, but interestingly omits sum information, making the referenced tag versions technically mutable, depending on how that is calculated).

Ignoring SLSA for a moment, I think the other recommended restrictions seem reasonable: MPA approvals for releases, signed tags, etc.