New to Claude Skills? Learn how to install them →

Gposthog on GitHub

Gating Production Deploys

Free

Control your production deploys with GitHub Actions.

by posthog37.6k stars on posthog/posthog
1 views
Updated Aug 11, 2026
Get this skill

Free · Opens the source repo

What Gating Production Deploys does

Gating Production Deploys is a skill designed for developers managing GitHub Actions workflows that push container images or dispatch production deployments. It ensures that these critical actions occur only under specified conditions, preventing unintended deployments from incorrect repositories. By utilizing the CD_DEPLOY_ENABLED variable, this skill allows users to define a single canonical deploy repository, effectively managing where production changes are made and ensuring that only authorized pushes trigger deployments.

When adding or editing workflows, this skill provides clear guidelines on how to gate production-related actions. It specifically focuses on scenarios such as pushing a production-tagged container image or dispatching a commit_state_update to the PostHog charts. The skill emphasizes that certain workflows, like those for GitHub releases or npm packages, should remain ungated to ensure they function correctly from public repositories. This targeted approach minimizes the risk of errors during deployment processes, making it particularly valuable for teams that prioritize reliability in their CI/CD pipelines.

The gating mechanism is implemented through simple conditional checks in the workflow YAML files. By following the provided patterns, developers can easily integrate the gating logic into their existing workflows. This skill is particularly useful for teams using GitHub Actions who want to enforce strict controls over their production deployments while maintaining flexibility for other types of workflows. It is aimed at developers and DevOps engineers who are looking to enhance their deployment processes and ensure that only the correct changes are pushed to production.

Overall, Gating Production Deploys provides a robust framework for managing production deployments in a controlled manner, reducing the likelihood of errors and improving the overall integrity of the deployment process.

When to use it

Use this skill when you need to manage production deploys and container image pushes from a single repository in GitHub Actions.

When not to use it

This skill is not suitable for workflows that involve public releases or non-production-related builds, as those should remain ungated.

What you can build with it

Production Deploy Management

Use this skill to enforce conditions on production deploys, ensuring only authorized changes are pushed.

Container Image Push Control

Implement gating on container image pushes to prevent accidental deployments from incorrect repositories.

CI/CD Pipeline Integrity

Maintain the integrity of your CI/CD pipeline by using this skill to manage when and how production changes are deployed.

How to install Gating Production Deploys

View source

1. Install with the skills CLI

npx skills add posthog/posthog/gating-production-deploys --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by posthog

Gating production builds and deploys

Container-image pushes and Charts deploy dispatches run from one canonical deploy repo, selected by the CD_DEPLOY_ENABLED variable. Gate every such step or it publishes/deploys from the wrong place.

Gate these when they run on push-to-master / schedule / workflow_dispatch:

  • a prod-tag container image push, and
  • a commit_state_update dispatch to PostHog/charts (plus its deployer-token step).

Don't gate:

  • Release/distribution workflows — GitHub release, npm, crate, Homebrew (e.g. build-phrocs.yml, release-cli.yml). They publish from public; leave them.
  • pull_request validation builds (gating them breaks contributor CI).
  • change-detection / setup jobs (use the org check only, not the variable).

The test is "pushes a prod image or triggers a deploy" — not "builds on master".

The gate

if: github.repository_owner == 'PostHog' && vars.CD_DEPLOY_ENABLED == 'true'

Use this instead of hardcoding github.repository == 'PostHog/posthog'.

Patterns

# whole job is the deploy/push (no PR builds) — gate the job:
if: github.repository_owner == 'PostHog' && vars.CD_DEPLOY_ENABLED == 'true'

# deploy job/step already keyed to master — add the gate:
if: github.repository_owner == 'PostHog' && vars.CD_DEPLOY_ENABLED == 'true' && github.ref == 'refs/heads/master'

# build job that also serves PRs — gate only the master arm of its `if`:
(github.event_name == 'push' && github.ref == 'refs/heads/master' && needs.changes.outputs.files == 'true'
  && github.repository_owner == 'PostHog' && vars.CD_DEPLOY_ENABLED == 'true')

# push step, master-only:
push: ${{ github.ref == 'refs/heads/master' && vars.CD_DEPLOY_ENABLED == 'true' }}
# push step, `push: true` (also pushes on PR for validation):
push: ${{ github.event_name == 'pull_request' || vars.CD_DEPLOY_ENABLED == 'true' }}

# reusable that pushes — add a `push` boolean input (default true), pass from caller:
#   with: { push: ${{ github.event_name == 'pull_request' || vars.CD_DEPLOY_ENABLED == 'true' }} }

Set CD_DEPLOY_ENABLED on the repo that should ship before merging, or master pushes skip the build/deploy. Lint with actionlint.

Examples: container-images-cd.yml (whole-job); cd-mcp-image.yml, livestream-docker-image.yml, cd-sandbox-base-image.yml (mixed PR+master); rust-docker-build.yml + _rust-build-images.yml (reusable push input). Counter-example, not gated: build-phrocs.yml.

Frequently asked questions about Gating Production Deploys

Similar skills