production-release-gating
Installation
SKILL.md
Gating production deploys to real releases
By default, a push/merge to main deploys to production. With
semantic-release you usually want the
opposite: previews on feature branches, but production only on an actual
release (a versioned chore(release): commit / a published GitHub Release).
There are three ways to enforce that. They have names, not letters, so you can pick one by name and record it (see "pick the flow" below):
| Release-Triggered Deploy | Promotion Branch | Build-Skip Gate | |
|---|---|---|---|
| One-liner | CI runs the deploy when a Release publishes | a release fast-forwards a production branch the platform watches |
a script cancels non-release builds on the platform |
| Who deploys | a workflow you control (GKE, self-hosted, dispatchable, or a platform CLI) | the platform's native git integration, but only off production |
the platform auto-builds every push; the script vetoes |
| The gate | a published Release triggers the deploy; plain pushes deploy nothing | production only advances on a published Release; main = staging |
the script skips the build unless it's a release commit |
| Portability | any dispatchable target (must disable native push-deploy — see below) | any host with a configurable production branch (Vercel, Netlify, CF Pages) — most portable | Vercel/Netlify only (platform-specific script) |
| Template | release-production.yml |
promote-to-production.yml |
vercel-ignore.sh |