mirror of
https://github.com/fsolla/teqo.git
synced 2026-11-12 22:13:05 +00:00
377a2c89b1
Some checks failed
Deploy / preflight (push) Has been cancelled
Deploy / verify (push) Has been cancelled
Deploy / deploy staging (teqo-staging) (push) Has been cancelled
Deploy / requeue when main advanced (push) Has been cancelled
Deploy / deploy production (teqo-1313) (push) Has been cancelled
O label ubuntu-latest migrou para Ubuntu 26.04 em out/2026 e o Playwright 1.58.2 não tem build para 26.04 (run 42095564329: 'Playwright does not support chromium on ubuntu26.04-x64'). Pina o job checks do ci-pr e o verify do deploy em ubuntu-24.04 até o bump do Playwright.
290 lines
13 KiB
YAML
290 lines
13 KiB
YAML
# Deploy (OPS71 — GitHub Actions; staging + production since OPS103;
|
|
# automatic start since OPS104; approval lane decoupled since OPS107).
|
|
#
|
|
# STARTS BY ITSELF: a `push` to `main` starts the run (OPS104 trigger 1) —
|
|
# the `preflight` job skips it when another deploy run is already
|
|
# queued/in_progress (a run `waiting` on the production approval does NOT
|
|
# count: a merge in that window starts a new run and both stay pending).
|
|
# `workflow_dispatch` is kept as the manual escape (rollback/re-dispatch) and
|
|
# never goes through the guard.
|
|
#
|
|
# REQUEUES ITSELF: after a green `deploy-staging`, the hosted `requeue` job
|
|
# compares main's head with the run's SHA and dispatches a new run from the
|
|
# new head when a merge landed mid-flight (OPS104 trigger 2). It stays OUTSIDE
|
|
# the `deploy-homeserver` group — a run waiting on the production approval
|
|
# must not block the requeue.
|
|
#
|
|
# Jobs (OPS103/OPS104):
|
|
# preflight — ubuntu-latest: push-only guard (OPS104 trigger 1).
|
|
# verify — ubuntu-latest (hosted): full cascade (guards for PR
|
|
# contracts are left out — they gate PRs, not
|
|
# production). Untouched by OPS103; it verifies the
|
|
# COMMIT once for both environments.
|
|
# deploy-staging — needs: [verify], environment: staging (no reviewer:
|
|
# the run itself is the deliberate act). Runs the
|
|
# same script with TEQO_ENV=staging (teqo-staging,
|
|
# 127.0.0.1:1314).
|
|
# deploy-production — needs: [deploy-staging], environment: production
|
|
# (required reviewer fsolla, configured in the repo).
|
|
# A red staging fail-closes production. Same script,
|
|
# TEQO_ENV=production (teqo-1313, 127.0.0.1:1313).
|
|
# NO concurrency group (OPS107): a job `waiting` on the
|
|
# approval must not occupy the shared deploy lane — the
|
|
# concurrency is evaluated before the environment gate,
|
|
# and holding the group blocked every later run's staging.
|
|
# requeue — hosted, after deploy-staging: re-dispatches when main
|
|
# advanced (OPS104 trigger 2).
|
|
#
|
|
# Both deploy jobs run on the GitHub self-hosted runner ON the homeserver
|
|
# (labels self-hosted + homeserver): the script executes locally — no SSH
|
|
# hop, no workstation involvement. Never moved into ci-pr.yml: a self-hosted
|
|
# job is code execution on the production machine, and only a run with the
|
|
# full verify suite green can reach it. The hosted job never reaches the
|
|
# homeserver; the self-hosted job never counts hosted minutes.
|
|
#
|
|
# The environment-specific builds CANNOT leave the homeserver (migrate
|
|
# pre-build on the env DB — OPS66 — and the compose network / local registry
|
|
# localhost:5000), which is exactly why the hosted jobs only verify/decide
|
|
# and the self-hosted jobs only build + deploy. Deploy is idempotent
|
|
# ("already deployed" guard in deploy-homeserver.sh) and serialized by ONE
|
|
# flock on the host (both environments). The `concurrency` group below lives
|
|
# ONLY on `deploy-staging` (OPS107) — it never waits on an approval, so it
|
|
# always drains; the staged `needs` chain serializes the environments inside
|
|
# one run. Production execution is serialized by that same chain, the single
|
|
# self-hosted runner and the host flock — never by a GitHub group.
|
|
#
|
|
# The deploy jobs fetch the repo from github.com (public) — TEQO_REPO_URL in
|
|
# deploy-homeserver.sh defaults there; the script runs to completion for the
|
|
# SHA of the run even if main advances during verify (OPS102).
|
|
#
|
|
# OPS104 supersedes the OPS102 "manual-only" anti-goal: only the START of
|
|
# the run is automatic. Production still publishes exclusively through the
|
|
# `production` environment approval; there is no auto-approve, no auto-retry
|
|
# and no cancel-old-runs automation.
|
|
|
|
name: Deploy
|
|
|
|
on:
|
|
push:
|
|
branches: [main]
|
|
workflow_dispatch:
|
|
|
|
permissions:
|
|
contents: read
|
|
|
|
env:
|
|
PAYLOAD_SECRET: test-only-secret-not-used-in-production
|
|
NEXT_PUBLIC_SITE_URL: http://localhost:3000
|
|
|
|
jobs:
|
|
preflight:
|
|
# OPS104 trigger 1 guard: skip this push when another deploy run is
|
|
# already queued/in_progress (a run `waiting` on the production approval
|
|
# does NOT count). Manual dispatches skip the guard (the step is
|
|
# push-only) and the output default keeps the dispatch path flowing.
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 5
|
|
permissions:
|
|
contents: read
|
|
actions: read
|
|
outputs:
|
|
should_deploy: ${{ steps.guard.outputs.should_deploy || 'true' }}
|
|
steps:
|
|
- uses: actions/checkout@v5
|
|
- name: Decide whether this push should deploy
|
|
id: guard
|
|
if: github.event_name == 'push'
|
|
run: node scripts/deploy-preflight.mjs
|
|
env:
|
|
GITHUB_TOKEN: ${{ github.token }}
|
|
|
|
verify:
|
|
needs: [preflight]
|
|
if: needs.preflight.outputs.should_deploy == 'true'
|
|
# Same pin as ci-pr: Playwright 1.58.2 has no ubuntu26.04 build and
|
|
# `ubuntu-latest` migrated to 26.04 in Oct 2026.
|
|
runs-on: ubuntu-24.04
|
|
timeout-minutes: 50
|
|
services:
|
|
# OPS71 — GitHub hosted: jobs run on the runner VM, so services are
|
|
# reached at localhost on PUBLISHED host ports (fixed — each run is its
|
|
# own VM). ONE service (OPS88): a deterministic reset (`pnpm db:reset`
|
|
# — drop schema → migrate → seed minimal) between the integration
|
|
# phase and the e2e build keeps e2e from inheriting int fixture
|
|
# residue, instead of a second container.
|
|
postgres-int:
|
|
image: postgres:17-alpine
|
|
env:
|
|
POSTGRES_USER: teqo
|
|
POSTGRES_PASSWORD: teqo
|
|
POSTGRES_DB: teqo_test
|
|
ports:
|
|
- 5432:5432
|
|
options: >-
|
|
--health-cmd "pg_isready -U teqo"
|
|
--health-interval 5s
|
|
--health-timeout 5s
|
|
--health-retries 12
|
|
steps:
|
|
- uses: actions/checkout@v5
|
|
with:
|
|
fetch-depth: 0
|
|
- uses: pnpm/action-setup@v6
|
|
- uses: actions/setup-node@v5
|
|
with:
|
|
node-version: 24
|
|
cache: pnpm
|
|
- run: pnpm install --frozen-lockfile
|
|
|
|
- name: Check test file locations
|
|
run: node scripts/check-test-locations.mjs
|
|
- name: Lint
|
|
run: pnpm lint
|
|
- name: Format check
|
|
run: pnpm format:check
|
|
- name: Typecheck
|
|
run: pnpm typecheck
|
|
- name: Knip
|
|
run: pnpm knip
|
|
- name: Check cycles
|
|
run: pnpm check:cycles
|
|
- name: Unit tests (full suite)
|
|
run: pnpm test:unit
|
|
|
|
- name: Prepare database URL
|
|
run: |
|
|
set -euo pipefail
|
|
echo "DATABASE_URL=postgresql://teqo:teqo@localhost:5432/teqo_test" >> "$GITHUB_ENV"
|
|
# vitest re-loads .env.test over the process env, so the service URL
|
|
# must win through the .env.test.local layer (same mechanism
|
|
# `pnpm worktree next` uses).
|
|
echo "DATABASE_URL=postgresql://teqo:teqo@localhost:5432/teqo_test" > .env.test.local
|
|
- name: Migrate
|
|
run: pnpm migrate
|
|
- name: Seed minimal
|
|
run: pnpm db:seed:minimal
|
|
- name: Integration tests (full suite)
|
|
env:
|
|
# vitest forks ≈ CPUs and each fork holds a Payload pool (max 10) →
|
|
# overflows the service Postgres' 100 clients. 4 forks stay well
|
|
# under. The unit step above stays CPU-relative (no DB).
|
|
VITEST_MAX_WORKERS: 4
|
|
run: pnpm test:int
|
|
|
|
- name: Reset database (drop → migrate → seed)
|
|
# OPS88: one Postgres per run — the e2e build starts from the same
|
|
# clean baseline (drop schema → migrate → seed:minimal) instead of a
|
|
# second container. The full suite always runs here, so only the
|
|
# `.next-e2e` build (below) exists — the default build is gone.
|
|
run: pnpm db:reset
|
|
|
|
- name: Cache Playwright browsers
|
|
uses: actions/cache@v4
|
|
with:
|
|
path: ~/.cache/ms-playwright
|
|
key: playwright-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}
|
|
restore-keys: |
|
|
playwright-${{ runner.os }}-
|
|
- name: Install Playwright chromium
|
|
run: pnpm exec playwright install --with-deps chromium
|
|
- name: Build for e2e
|
|
# Same dir the Playwright webServer serves (playwright.config.ts
|
|
# falls back to '.next-e2e'; gate-ci.mjs builds there too).
|
|
# NEXT_PUBLIC_SITE_URL is inlined at build time, so the canonical
|
|
# `.test` origin must reach THIS build — it is what lets the agenda
|
|
# feed dialog generate a link under the production build (OPS83).
|
|
run: pnpm build
|
|
env:
|
|
NEXT_DIST_DIR: .next-e2e
|
|
NEXT_PUBLIC_SITE_URL: https://feed.e2e.teqo.test
|
|
# S15 — deterministic cutout stub: the e2e build never downloads the
|
|
# MediaPipe wasm nor runs inference.
|
|
NEXT_PUBLIC_CARDS_CUTOUT_STUB: '1'
|
|
NEXT_PUBLIC_FACE_SEARCH_STUB: '1'
|
|
- name: E2E tests (full suite, single job, 4 workers)
|
|
# Explicit CI workers; the local default stays 2 (playwright.config.ts).
|
|
# No `--` separator: pnpm would forward it verbatim to playwright and
|
|
# the flag would be parsed as a file pattern ("No tests found").
|
|
env:
|
|
PLAYWRIGHT_WORKERS: 4
|
|
NEXT_PUBLIC_SITE_URL: https://feed.e2e.teqo.test
|
|
run: pnpm test:e2e
|
|
|
|
deploy-staging:
|
|
name: deploy staging (teqo-staging)
|
|
# OPS103 (+OPS104): same SHA, same verify, own environment — no reviewer
|
|
# (the run was started deliberately: push to main or manual dispatch);
|
|
# production is the approval that matters. The `main` guard makes a
|
|
# dispatch from a branch/tag a no-op for deploys.
|
|
needs: [verify]
|
|
if: needs.verify.result == 'success' && github.ref == 'refs/heads/main'
|
|
environment: staging
|
|
runs-on: [self-hosted, homeserver]
|
|
timeout-minutes: 60
|
|
concurrency:
|
|
# Shared homeserver compose/workspace: never two staging deploys at once
|
|
# across runs. Only staging holds this group (OPS107): it never waits on
|
|
# an approval, so it always drains — production has NO group because a
|
|
# `waiting` approval would block every later run's staging (the
|
|
# concurrency is evaluated before the environment gate). `queue: max`:
|
|
# the default single-slot queue cancels a previously pending deploy when
|
|
# a new dispatch arrives, even with cancel-in-progress false — deploys
|
|
# must wait their turn (OPS102: run to completion).
|
|
group: deploy-homeserver
|
|
cancel-in-progress: false
|
|
queue: max
|
|
env:
|
|
TEQO_ENV: staging
|
|
steps:
|
|
- uses: actions/checkout@v5
|
|
- name: Deploy teqo-staging on the homeserver
|
|
run: bash scripts/deploy-homeserver.sh "$GITHUB_SHA"
|
|
|
|
requeue:
|
|
name: requeue when main advanced
|
|
# OPS104 trigger 2: after a green staging, dispatch a fresh run from
|
|
# main's new head when a merge landed mid-flight. Hosted and OUTSIDE the
|
|
# `deploy-homeserver` group: a run `waiting` on the production approval
|
|
# holds that group and must not block the requeue. `actions: write` is the
|
|
# documented anti-recursion exception — workflow_dispatch events DO create
|
|
# runs for the built-in GITHUB_TOKEN (no secret needed).
|
|
needs: [deploy-staging]
|
|
if: needs.deploy-staging.result == 'success' && github.ref == 'refs/heads/main'
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 5
|
|
permissions:
|
|
contents: read
|
|
actions: write
|
|
steps:
|
|
- uses: actions/checkout@v5
|
|
- name: Requeue when main advanced during the run
|
|
run: node scripts/deploy-requeue.mjs
|
|
env:
|
|
GITHUB_TOKEN: ${{ github.token }}
|
|
|
|
deploy-production:
|
|
name: deploy production (teqo-1313)
|
|
# OPS53 + OPS71 + OPS103 + OPS104 + OPS107. Runs on the GitHub self-hosted
|
|
# runner ON the homeserver (labels self-hosted + homeserver): the script
|
|
# executes locally — no SSH hop, no workstation involvement. Never wired in
|
|
# ci-pr.yml: a self-hosted job is code execution on the production
|
|
# machine, and only a run with the full verify suite green can reach it
|
|
# (the automatic start and the manual dispatch share the same gate).
|
|
# `needs: [deploy-staging]` makes a red staging fail-close production; the
|
|
# environment `production` (required reviewer, configured in the repo) is
|
|
# the approval gate — and the ONLY one. No concurrency group (OPS107): a
|
|
# job `waiting` here must not hold the shared deploy lane (it blocked every
|
|
# later run's staging, forcing old runs to be approved to reach the
|
|
# newest). Execution stays serialized by the needs chain, the single
|
|
# self-hosted runner and the host flock in deploy-homeserver.sh.
|
|
needs: [deploy-staging]
|
|
if: needs.deploy-staging.result == 'success' && github.ref == 'refs/heads/main'
|
|
environment: production
|
|
runs-on: [self-hosted, homeserver]
|
|
timeout-minutes: 60
|
|
env:
|
|
TEQO_ENV: production
|
|
steps:
|
|
- uses: actions/checkout@v5
|
|
- name: Deploy teqo-1313 on the homeserver
|
|
run: bash scripts/deploy-homeserver.sh "$GITHUB_SHA"
|