Woodpecker CI migration table — all 86 GHA workflows

Date: 2026-07-04 UTC ADR: docs/architecture/adr/0135-woodpecker-ci-full-migration-phases3-5.md Scope: Every .github/workflows/*.yml file + 5 composite actions

Wave D status — 2026-07-07 (#4019)

Retired buckets: Phase 2 (3) + Wave A (31) + RETIRE-GHA-NATIVE (6) + DISABLE/ios-ci (1) + Wave C confirmed (4) + Wave B crons batch 1 (6) (#4067/#4068)

WP gaps remaining: Wave B crons (13 remaining) + Wave C deploy gap (22) — Wave B batch 1 (#4067/#4068) ported 2026-07-07.

Wave B crons batch 1 status (2026-07-07, #4067/#4068):

billing-collector-cron.yml active on GHA: schedule was already commented out (PAUSED since 2026-05-15). WP YAML written for event: manual only. Cron registration and GHA retirement deferred until #2159 (Postgres migration) unblocks runtime verification.

Full execution record: docs/architecture/adr/0135-woodpecker-ci-full-migration-phases3-5.md § Wave D execution record.

How to read this table

Bucket: - MIGRATE — port to a .woodpecker/*.yaml pipeline; wave column shows which execution wave the port ships in. - RETIRE-GHA-NATIVE — workflow relies on a GHA-specific trigger or action (workflow_run, workflow_call, release-please) with no direct WP equivalent. Column "Replacement in WP" shows what covers the function. - DISABLE — operator-deferred per ADR-0134. File stays; no WP equivalent created until the deferred decision is revisited. - PORT-COMPOSITE — not a workflow file; a composite action ported to a reusable scripts/ci/wpc_* script used inline by migrated pipelines.

Wave: - Phase 2 (done) — pilot WP pipeline already running and green. - Wave A — PR gates, lint, light push CI, manual-dispatch workflows, and low-risk crons. Entry criterion: Phase 2 complete (✓). - Wave B — heavy CI (postgres service containers), remaining crons, e2e/ZAP tests, and nightly-security-scan full port. Entry criterion: Wave A 7-day soak + postgres service container smoke confirmed on AL2023. - Wave C — deploy/release pipeline, gatekeeper, promote-to-main. Entry criterion: Wave B parity + Console Ops Dispatch sub-card filed and in-flight. - Wave D — decommission (disable + archive GHA files). Entry criterion: Wave C 14-day prod soak.

Section 1 — PORT-COMPOSITE (5 composite actions)

These are .github/actions/*/action.yml files, not workflow files. They have no direct WP equivalent; each is ported to an inline scripts/ci/wpc_* script copied by value into every migrated pipeline that needs it.

Section 2 — DISABLE (1 workflow)

Section 3 — RETIRE-GHA-NATIVE (6 workflows)

Section 4 — MIGRATE: full per-workflow table

Phase 2 pilots (already running in WP; GHA counterpart still active during soak)

Wave A — PR gates, lint, push CI, low-risk crons, manual dispatch

Wave A total: 30 workflows + 2 Phase 2 pilot completions (alembic-version-cron, maxmind-asn-refresh)

Wave B — heavy CI, postgres service, remaining crons, e2e/ZAP

Entry criterion: Wave A 7-day soak + postgres:15 service container smoke green on Amazon Linux 2023 Docker agent.

Wave B total: 22 workflows (20 new + 2 postgres step additions to Wave A pipelines)

Wave C — deploy, release, gatekeeper pipelines

Entry criterion: Wave B 7-day parity soak; Console Ops Dispatch sub-card filed and in active development; branch-protection WP checks are sole required gate on develop.

Deploy pipelines are migrated staging-first within Wave C: each pipeline is enabled for branch: release (staging) first, soaked for 5 days, then branch: main (production) is enabled. The gatekeeper and promote-to-main pipelines go last (after all staging deploys are proven).

Wave C total: 26 workflows

Wave D — decommission (not a migration wave; no new WP pipelines)

All remaining GHA workflows are disabled and archived. No new .woodpecker/*.yaml files are created in this wave.

Section 5 — Trigger mapping reference

Quick reference for translating GHA trigger syntax to Woodpecker v3 when: blocks:

Section 6 — Wave entry criteria and rollback stances

Wave A

Entry: Phase 2 complete (✓). Composite action scripts (wpc_*.py/wpc_*.sh) merged. WP org-level secrets set. Gate to declare A complete: 7-day soak; all 30 Wave A WP pipelines run successfully at least twice; WP branch-protection checks added alongside GHA (PRs pass both). Rollback: Disable WP pipelines in WP admin UI. GHA workflows remain active; branch-protection GHA checks remain required. Zero blast radius.

Wave B

Entry: Wave A gate passed. postgres:15 service container smoke green on a c6a.xlarge AL2023 agent (run once manually; confirm pg_isready passes before enabling the step in ci-pr.yaml and ci-develop.yaml). Gate to declare B complete: 7-day soak; 20+ successful backend-tests-postgres WP runs; all remaining crons green twice. Branch protection swapped to WP-only on develop. Rollback: Re-enable GHA check names in branch protection (5-minute operation); disable WP backend-postgres step via pipeline YAML PR.

Wave C

Entry: Wave B gate passed. Console Ops Dispatch sub-card (C-console) in active development (does not need to be merged; just filed and understood). Operator has confirmed prod deploy authorization design (WP secret event restriction) is acceptable. Sequencing within Wave C: 1. Enable staging-only deploys (branch: release) for all deploy pipelines. 2. 5-day staging soak: run 3+ full release-* tag → staging deploy cycles via WP. 3. Enable gatekeeper and promote-to-main pipelines. 4. Enable prod deploys (branch: main). Merge Console Ops Dispatch sub-card. Gate to declare C complete: 2+ prod deploys via WP; no GHA fallback needed; Console Ops Dispatch calls WP API successfully. Rollback: Re-enable GHA deploy workflows by removing the if: false disable flag (or via gh workflow enable). Each workflow is independently reversible in < 5 minutes.

Wave D

Entry: Wave C 14-day prod soak. No deploy incidents requiring GHA fallback. Work: Bulk disable GHA workflows; set GHA spending limit; build /onboard-ci. Rollback: GHA workflows are disabled, not deleted, for 30 days. Re-enable via gh workflow enable <file> if an emergency rollback is needed. After 30-day archive, rollback requires a git revert of the archive commit — operationally acceptable given the 30-day soak.

Section 7 — Branch protection API changes

develop branch (changes during Wave A + Wave B)

Wave A addition (add WP checks alongside existing GHA checks):

PATCH /repos/raxx-app/TradeMasterAPI/branches/develop/protection
{
  "required_status_checks": {
    "strict": true,
    "checks": [
      {"context": "PR Gates / Backend tests"},
      {"context": "CI — develop / Backend tests"},
      {"context": "ci/woodpecker/ci-pr/backend-tests-postgres"},
      {"context": "ci/woodpecker/ci-pr/frontend-tests"},
      {"context": "ci/woodpecker/ci-pr/sprint-readiness-gate"},
      {"context": "ci/woodpecker/ci-pr/base-branch-lint"},
      {"context": "ci/woodpecker/migration-collision-check/check"},
      {"context": "ci/woodpecker/ci-develop/backend-tests-postgres"}
    ]
  }
}

Wave B removal (remove GHA checks; keep only WP):

{
  "required_status_checks": {
    "strict": true,
    "checks": [
      {"context": "ci/woodpecker/ci-pr/backend-tests-postgres"},
      {"context": "ci/woodpecker/ci-pr/frontend-tests"},
      {"context": "ci/woodpecker/ci-pr/sprint-readiness-gate"},
      {"context": "ci/woodpecker/ci-pr/base-branch-lint"},
      {"context": "ci/woodpecker/migration-collision-check/check"},
      {"context": "ci/woodpecker/ci-develop/backend-tests-postgres"}
    ]
  }
}

Note: The exact WP check context names depend on the .woodpecker/*.yaml pipeline filenames and step names written in Wave A. Wave A sub-card A7 audits the actual check names reported by WP after the first successful run before executing the branch protection API call. Do not hardcode these names before verifying.

release and main branches

Existing required checks on release and main are likely gatekeeper-related checks, not PR-CI checks (since merges are automated via bot). Audit in Wave C sub-card C-bp before touching. Pattern is the same: add WP check names alongside GHA during Wave C staging soak, swap to WP-only after prod cutover confirmed.