https://github.com/stablekernel/cascade-example-rollback-dispatch
Fleet example: proves the repository_dispatch rollback trigger live
https://github.com/stablekernel/cascade-example-rollback-dispatch
Last synced: 14 days ago
JSON representation
Fleet example: proves the repository_dispatch rollback trigger live
- Host: GitHub
- URL: https://github.com/stablekernel/cascade-example-rollback-dispatch
- Owner: stablekernel
- Created: 2026-06-26T18:20:24.000Z (about 1 month ago)
- Default Branch: main
- Last Pushed: 2026-07-19T19:58:55.000Z (20 days ago)
- Last Synced: 2026-07-19T21:05:38.473Z (20 days ago)
- Size: 334 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# cascade-example-rollback-dispatch
A minimal cascade example whose purpose is to prove the `repository_dispatch`
rollback entry point live.
The manifest declares two environments (`staging`, then `prod`), one build, and
one deploy, and opts the generated rollback workflow into a `repository_dispatch`
trigger:
```yaml
rollback:
repository_dispatch:
types: [rollback-requested]
```
With that opt-in, `cascade-rollback.yaml` carries both the manual
(`workflow_dispatch`) and the external (`repository_dispatch`) entry points, and
each rollback parameter is read as
`github.event.inputs. || github.event.client_payload.` so an external
system can drive the same rollback by calling the dispatches API.
Rollback targets `prod`, the promoted-into environment. The first environment
(`staging`) tracks trunk and is never promoted into, so it carries no rollback
history and is reverted with a merge to trunk rather than a rollback. `prod`
gains its history from promotion, which is why the ring has two environments.
## What the scenario suite proves
`scenario-suite.yaml` seeds `staging` on a merge and promotes it to `prod`,
advances `staging` and promotes a second version to `prod` (leaving the earlier
version in prod's deploy-history ring), then fires a real `repository_dispatch`
rollback:
```bash
gh api "repos/$REPO/dispatches" -X POST \
-f event_type=rollback-requested \
-f 'client_payload[environment]=prod' \
-F 'client_payload[dry_run]=false'
```
It then asserts the real effect: prod reverts to the prior deploy's SHA and
version and is marked diverged (`ref=rollback/prod`). This is the only live
coverage of the `client_payload` coalesce path.
## Layout
- `.github/manifest.yaml` - the cascade manifest (staging then prod, rollback
dispatch on).
- `.github/workflows/orchestrate.yaml`, `promote.yaml`, `cascade-hotfix.yaml`,
`cascade-rollback.yaml` - generated by `cascade generate-workflow`; do not edit
by hand.
- `.github/workflows/build-app.yaml`, `deploy-app.yaml` - the build and deploy
callbacks the pipeline drives.
- `.github/workflows/scenario-suite.yaml` - the live validation driver.
- `src/` - the source of record a merge changes to drive orchestrate.
Regenerate the workflows after a manifest change:
```bash
cascade generate-workflow --config .github/manifest.yaml --force
```