Made by@slashcloneRelease on green
@slashclone/release-on-green
Set up a release pipeline with no manual gates: when CI passes on main, migrate the database, deploy, run a smoke test, and roll back on its own if the smoke test fails. Writes the GitHub Actions workflow for you to review; never deploys or stores secrets itself.
SkillDevOpsv0.1.0 (latest)
- Activity
- New: be the first to try it
- Installs
- 0 installs
- Likes
- 0 likes
- Clones
- 0 clones
- 1---
- 2name: release-on-green
- 3description: Set up an automatic release pipeline that ships every green commit on main, smoke tests production, and rolls back on failure. Use when someone wants deploys to be automatic unless something fails.
- 4---
- 6# Release on green
- 8Goal: every commit that passes CI on the main branch ships to production on its own, and a bad deploy undoes itself. People only step in when something fails.
- 10## The pipeline
- 121. **Trigger:** `workflow_run` on the CI workflow, only when it concluded `success`, only for the main branch. Never on pull requests.
- 132. **Concurrency:** one release at a time, `cancel-in-progress: false`, so a migration is never cut off. Let CI cancel older runs instead, so the newest release includes everything.
- 143. **Record what is live** before changing anything (the current deployment id or image), so rollback has a target.
- 154. **Migrate** the database with the project's own migration command. Migrations must be backwards compatible with the code that is still live (add columns before using them; drop them a release later).
- 165. **Deploy** the web app, then any other services whose files changed (compare the commit range, skip what did not change).
- 176. **Post-deploy hooks:** anything that must re-register with the new deploy (job queues, webhooks).
- 187. **Smoke test** production with a script that retries for about two minutes (see the production-smoke-test kit).
- 198. **Roll back** to the recorded deployment if the smoke test fails, then fail the run so the team is notified.
- 21## Steps
- 231. Read the existing CI workflow and the deploy commands the project already uses. Ask which hosting providers are in play; do not guess.
- 242. Write `.github/workflows/release.yml` with the steps above. Pin every action to a full commit SHA with the version in a comment.
- 253. List the repository secrets the workflow needs (names only). Tell the person to add them with `gh secret set NAME`, typing the value themselves. Never ask for or print a secret value.
- 264. If the host also deploys on every git push, turn that off in its config so there is one path to production.
- 275. Explain how to roll back by hand and where the run logs are.
- 29## Rules
- 31- No manual approval steps unless the person asks for one.
- 32- Never put secrets in the workflow file, logs, or commit messages.
- 33- Least privilege: `permissions: contents: read` at the top, wider only on the job that needs it.