DRAFT: automate release workflow #486
Conversation
| on: | ||
| push: | ||
| tags: | ||
| - "v*" |
There was a problem hiding this comment.
If this only occurs after a tag is created, what benefit does it provide?
| # Defence in depth: also require multiple approvals from: | ||
| # Settings -> Environments -> release -> Deployment protection rules -> Required reviewers | ||
| # | ||
| if: ${{ !contains( fromJson('["frenchi"]'), github.actor ) }} |
There was a problem hiding this comment.
Is there any way to tie this to a team, such as @modelcontextprotocol/go-sdk?
|
@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? |
|
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. |
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:
e.g.
gh release verify v0.5.0 -R modelcontextprotocol/go-sdkDemo
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: