gating-production-deploys

โดย posthog

ใช้เมื่อเพิ่มหรือแก้ไขเวิร์กโฟลว์ GitHub Actions ที่พุชอิมเมจคอนเทนเนอร์ไปยังรีจิสทรี (ECR/ghcr/Docker Hub ผ่าน build-push-action) หรือส่งคำขอ...

npx skills add https://github.com/posthog/posthog-foss --skill gating-production-deploys

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.

Skills เพิ่มเติมจาก posthog

managing-experiment-lifecycle
posthog
แนะนำการเปลี่ยนสถานะการทดลอง: การเริ่ม, หยุดชั่วคราว, ดำเนินต่อ, สิ้นสุด, จัดส่งรูปแบบ, เก็บถาวร, รีเซ็ต, และทำซ้ำ ครอบคลุมเงื่อนไขเบื้องต้น...
official
configuring-experiment-analytics
posthog
Configures the analytics side of a PostHog experiment — exposure criteria (default `$feature_flag_called` vs custom exposure events), primary and secondary…
official
error-tracking-hono
posthog
การติดตามข้อผิดพลาดของ PostHog สำหรับ Hono
official
error-tracking-react
posthog
PostHog การติดตามข้อผิดพลาดสำหรับ React
official
integration-android
posthog
PostHog integration สำหรับแอปพลิเคชัน Android
official
integration-ruby
posthog
PostHog การผสานรวมสำหรับแอปพลิเคชัน Ruby ใดๆ ที่ใช้ Ruby SDK
official
tuning-incremental-sync-config
posthog
การกำหนดค่าการซิงค์จะอยู่บน ExternalDataSchema และสามารถเปลี่ยนแปลงได้ตลอดเวลาผ่าน external-data-schemas-partial-update การเปลี่ยนแปลงส่วนใหญ่จะไม่ทำลายข้อมูล (มีผลในการซิงค์ครั้งถัดไป) แต่บางอย่าง (การเปลี่ยน sync_type, การเปลี่ยนคีย์หลัก) จำเป็นต้องจัดการอย่างระมัดระวังเพื่อหลีกเลี่ยงการทำให้ข้อมูลที่ซิงค์เสียหาย
official
instrument-integration
posthog
ใช้สกิลนี้เพื่อเพิ่ม PostHog SDK ลงในแอปพลิเคชัน ใช้เมื่อตั้งค่า PostHog เป็นครั้งแรก หรือตรวจสอบ PR ที่ต้องการการเริ่มต้นใช้งาน PostHog ครอบคลุมการติดตั้ง SDK การตั้งค่า provider และการกำหนดค่าพื้นฐาน รองรับเฟรมเวิร์กหรือภาษาใดก็ได้
official