posthog/posthog

gating-production-deploys

Use when adding or editing a GitHub Actions workflow that pushes a container image to a registry (ECR/ghcr/Docker Hub via build-push-action) or dispatches a production deploy (a commitstateupdate repositorydispatch to PostHog/charts).

소스 보기
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

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

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

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

Patterns

yaml
# 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.

같은 저장소의 Skills

더 많은 Skills

모든 Skills
posthog
공식

adding-personhog-rpc

Guide for adding a new RPC to personhog-replica and personhog-router. Covers eligibility checks, proto definition, code generation for Python and Node.js clients, Rust implementation (storage trait, postgres queries, service handler, router wiring), and index compatibility validation. Use when adding a new gRPC endpoint to personhog, migrating a Django ORM query to personhog, or extending the personhog service API.

설치 수
1
GitHub Stars
4만
업데이트
10월 8일
posthog
공식

adding-project-secret-api-key-auth

How to gate a PostHog API endpoint with project secret API key (PSAK) auth — a project-scoped, user-less service credential. Use when adding PSAK support to a viewset action, allowing a new scope for PSAKs, handling synthetic users (ProjectSecretAPIKeyUser), or choosing PSAK-aware rate throttles. Trigger terms: PSAK, ProjectSecretAPIKey, project secret API key, phs token, service auth, programmatic endpoint auth.

설치 수
1
GitHub Stars
4만
업데이트
10월 8일
posthog
공식

adopting-generated-api-types

Use when migrating frontend code from manual API client calls (api.get, api.create, api.surveys.get, api.dashboards.list, new ApiRequest()) and handwritten TypeScript interfaces to generated API functions and types. Triggers on files importing from lib/api, files with api.get . , manual interface definitions that duplicate backend serializers, or any frontend file that constructs API URLs by hand. Covers the full replacement workflow — finding the generated equivalent, swapping imports, adapting

설치 수
1
GitHub Stars
4만
업데이트
10월 8일
posthog
공식

depot-container-builds

Configures and runs Depot remote container builds using depot build and depot bake. Use when building Docker images, creating Dockerfiles with Depot, pushing images to registries, building multi-platform/multi-arch images (linux/amd64, linux/arm64), debugging container build failures, optimizing Dockerfile layer caching, using docker-bake.hcl or docker-compose builds, or migrating from docker build / docker buildx build to Depot. Also use when the user mentions depot build, depot bake, container

설치 수
1
GitHub Stars
4만
업데이트
10월 8일