promote-to-prod
Skill189 starsChanged 9 months agoMITView on GitHub
Promote the duckgres control-plane image to prod from the CLI — resolve the built image ref from the charts state file, fire the charts Promote-to-Prod workflow, and watch it through the approval gate. Use when the user says "promote duckgres", "ship the CP to prod", "roll prod", or asks which image ref to promote.
In this repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- scripts/client-compat/CLAUDE.mdCLAUDE.md
- ducklake-testSkill
- multitenant-downSkill
- multitenant-upSkill
The file
Files
Promote duckgres to prod
Prod promotion is manual by policy: state/duckgres.yaml in PostHog/charts
has require_prod_approval: true, so the ONLY path to prod is the charts
repo's promote-to-prod.yml workflow, gated by required reviewers on the
prod-promote-<team> GitHub environment. The result posts to
#alerts-managed-warehouse.
How images reach the state file (no action needed)
Merge to duckgres main → container-image-cd.yml builds per-arch images +
a multi-arch manifest, then repo-dispatches commit_state_update to
PostHog/charts → the deploy bot writes state.duckgres.image.sha and
auto-promotes image.dev (mw-dev rolls immediately). The promotable ref is
the MULTI-ARCH MANIFEST digest in the state file — never a per-arch digest,
and never the .dockerbuild artifacts on the CD run (those are build
provenance).
Procedure
- Resolve the ref (and sanity-check it is the merge you expect):
STATE=$(gh api -H "Accept: application/vnd.github.raw" \
/repos/PostHog/charts/contents/state/duckgres.yaml)
DEV=$(echo "$STATE" | yq '.state.duckgres.image.dev')
PROD=$(echo "$STATE" | yq '.state.duckgres.image.prod')
echo "dev: $DEV"
echo "prod: $PROD"
# The <git-sha> prefix of $DEV must be the duckgres main commit you intend
# to ship. If dev != sha the CD/deploy-bot hop hasn't landed yet — wait.- Show the delta going out (what prod is about to receive):
git log --oneline "${PROD%%@*}..${DEV%%@*}"- Fire the promotion (parks at the approval gate — nothing deploys yet):
gh workflow run promote-to-prod.yml -R PostHog/charts \
-f app=duckgres -f image="$DEV"
sleep 8
RUN_URL=$(gh run list -R PostHog/charts --workflow=promote-to-prod.yml \
--limit 1 --json url --jq '.[0].url')
echo "$RUN_URL"
# Land the approver directly on the approval page:
open "$RUN_URL"- Approval: a required reviewer approves the pending deployment on the run page just opened. Never self-approve programmatically on the operator's behalf — open the page and wait.
- Watch to completion (after approval):
gh run watch <run-id> -R PostHog/charts --exit-status
# Verify the write landed:
gh api -H "Accept: application/vnd.github.raw" \
/repos/PostHog/charts/contents/state/duckgres.yaml | yq '.state.duckgres.image.prod'ArgoCD picks up the new image.prod and rolls the prod control plane;
watch pods with kubectl -n duckgres get pods -w if verification beyond
ArgoCD is wanted.
Notes
run-nameshows as "<actor>promoted duckgres to prod (<image>)" in the Actions list; the commit the run page header shows is main's HEAD at dispatch, NOT the commit the run creates — the created commit is linked from the job summary.- The cache-proxy image is a separate deploy target: same workflow with
-f app=duckgres-cache-proxy(state filestate/duckgres-cache-proxy.yaml). - Rollback = promote the previous known-good ref (visible in
git log -- state/duckgres.yamlin the charts repo) through the same workflow.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

