gh-deploy-pipeline
Deploy Pipeline
Push-to-main, lane-aware, artifact-driven. Detect what changed, build it once, run e2e against the built artifact, then deploy that same artifact per host. Frontends ship to a static host (Cloudflare Pages, AWS Amplify); backends ship a container image to GHCR and cut over on the VPS. The shape is identical across both.
Pipeline Shape
push to main
└─► detect-changes (paths-filter or turbo --affected → per-lane outputs)
└─► verify-<lane> (lint + typecheck + test + build → upload artifact)
└─► e2e-<lane> (download artifact, run e2e against it)
└─► deploy-<lane> (download artifact + load env → ship to host)
└─► smoke / health-check (hit the deployed URL)
Each lane is independent: a web-only change builds and deploys only web, leaving api untouched. Verify, e2e, and deploy run cancellable concurrency groups; the deploy job uses a non-cancellable group per (env, lane) so two pushes never race the same target.
A separate deploy.yml (workflow_dispatch) lets a human re-deploy a specific ref + lane without re-running verify — same composite actions, same concurrency group, no path detection.
Workflow
- Inspect the current repo first: existing
.github/workflows/*,.github/actions/*, hosting scripts, infra files, and recent failing runs. If the org has a known-good sibling repo for the same host, read that workflow before choosing actions or inventing shell. - Confirm prerequisites:
mainis the deploy branch, the host (Cloudflare/Amplify/VPS) is reachable, and the secret store (1Password Connect, AWS OIDC, or repo secrets) is wired. - Pick the deploy target — references/targets.md covers Cloudflare Pages, AWS Amplify, and GHCR + VPS (blue/green with Traefik). Each gets its own composite action under
.github/actions/<name>so the workflow stays declarative. Prefer a working repo-local or sibling composite action over a fresh marketplace guess. - Author
.github/workflows/main.ymland (optionally).github/workflows/deploy.ymlper references/workflows.md. Keep thechanges → verify → e2e → deploytopology; do not collapse stages. - Stand up change detection:
dorny/paths-filter@v4for simple per-app rules, or a Turbo--affectedwalker for monorepos that need package-graph awareness. Output one boolean per deploy lane. - Wire env loading via references/secrets.md — 1Password Connect for application env, AWS OIDC for cloud creds, GHCR auto-token for image push. Never paste secrets directly into workflow YAML.
- Set deploy concurrency: cancellable for verify/e2e, non-cancellable for deploy. Group by
(env, lane)so a web deploy does not block an api deploy, but two web deploys serialize. - Add a smoke step after deploy: hit the deployed URL or container health endpoint and fail the job if it is not 200. A green deploy that does not serve traffic is a failed deploy.
- Validate end-to-end: PR (verify only, no deploy) → merge a change touching one lane → watch detect → verify → e2e → deploy → smoke → publish summary. Confirm only the touched lane ran.
- Cross-check references/troubleshooting.md when a deploy is stuck, racing, or shipping the wrong artifact.
Examples
Load detailed workflow snippets from references/workflows.md only after the target lanes and host are known; load references/targets.md only for the selected host.
Minimal deploy anchor:
deploy-web:
needs: [verify-web, e2e-web]
if: ${{ needs.verify-web.result == 'success' && needs.e2e-web.result == 'success' }}
concurrency: { group: deploy-production-web, cancel-in-progress: false }
steps:
- uses: actions/download-artifact@v8
with: { name: web-dist, path: apps/web/dist }
- run: curl -fsS https://web.example.com/healthz
Guardrails
- One artifact end-to-end: e2e and deploy both consume the artifact verify uploaded. Never rebuild inside deploy.
- Repo precedent beats generic advice. If a sibling repo already deploys to the same host successfully, preserve that workflow/action shape unless you can point to a concrete mismatch.
- Deploy concurrency is non-cancellable per
(env, lane)and shared betweenmain.ymlanddeploy.yml. - A deploy job is not green until its smoke step has hit the deployed URL.
More from uinaf/agents
docs-keeper
Maintain project documentation with clear human/agent separation. Use when setting up a new project, auditing docs, creating plans, or managing agent working memory. Triggers include "set up docs", "create a plan", "audit documentation", "init project structure", or any task involving project documentation conventions.
10gh-release-pipeline
Set up or align a GitHub Actions release pipeline for a versioned package, library, CLI, or marketplace action. Use when standardizing repos around the verify-then-release shape: push to main → guardrails → semantic-release tags + publishes → version-bump commit back to main with `[skip ci]`. Pairs with `gh-deploy-pipeline` for running apps; use for publishing versioned artifacts to a registry, not deploying a running service.
10verify
Self-check your own completed change before handing off to `review` — the pre-review sanity pass. Use when you want to check your work, run checks, validate changes, make sure a change is ready, test it end-to-end, run repo guardrails (lint, typecheck, tests, build), exercise the real surface with evidence, and catch obvious self-correctable issues. Produces a `ready for review` / `needs more work` / `blocked` verdict — never a ship decision. If the repo cannot be booted or exercised reliably, hand off to `agent-readiness`. If auditing someone else's diff, branch, or PR, use `review` instead.
9viteplus
Migrate or align frontend repositories to the stock VitePlus workflow. Use when standardizing package or monorepo repos around `vp`, `voidzero-dev/setup-vp`, `vite-plus/test`, and VitePlus-native CI, test, packaging, and hook flows. Default to replacing direct package-manager and Vitest wiring with the VitePlus equivalents unless the repo has a proven exception.
9review
Independently audit existing code, diffs, branches, or pull requests using concern-specific reviewer personas and evidence. Use when triaging risk in a PR, deciding whether a change is safe to ship, or following up on a `verify` pass to make the call the builder cannot make on their own work. Produces a `ship it` / `needs review` / `blocked` verdict. Do not use to self-check a change you just authored; use `verify` for that.
9agent-readiness
Audit and build the infrastructure a repo needs so agents can work autonomously — boot scripts, smoke tests, CI/CD gates, dev environment setup, observability, and isolation. Use when a repo can't boot, tests are broken or missing, there's no dev environment, agents can't verify their work, or agents need human help to get anything done. Do not use for reviewing an existing diff or for documentation-only cleanup.
9