CI/CD with GitHub Actions

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly

  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

name: CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  verify:
    runs-on: ubuntu-latest
    timeout-minutes: 20

name: Deployment Gate Example

on:
  workflow_dispatch:
    inputs:
      image_sha:
        description: Full commit SHA already published by release-images
        required: true

permissions:
  contents: read
  id-token: write

concurrency:
  group: production
  cancel-in-progress: false

jobs:
  gate:
    runs-on: ubuntu-latest

name: Integration Tests

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  api-integration:
    runs-on: ubuntu-latest
    timeout-minutes: 25

    services:
      postgres:
        image: postgres:18
        env:

name: Build Release Images

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  packages: write

concurrency:
  group: release-images-${{ github.ref }}
  cancel-in-progress: false

jobs:
  images:
    runs-on: ubuntu-latest
    timeout-minutes: 30

# TaskFlow CI/CD Architecture

Pull request -> CI + integration tests -> merge protection -> main -> build immutable web/api images -> GHCR -> protected environment -> Phase 34 deployment.

Rules:
1. CI proves source.
2. Release builds one immutable artifact per commit.
3. Deployment promotes an already-built artifact; it does not rebuild source.
4. Production environment may require approval and exposes secrets only after protection rules pass.
5. Prefer OIDC to long-lived cloud credentials.
6. `GITHUB_TOKEN` gets only the permissions required by each workflow/job.

# TaskFlow GitHub Actions Snapshot

This snapshot is educational and intentionally stops before actual cloud deployment. Phase 33 produces tested, immutable container candidates. Phase 34 connects those candidates to the selected hosting platform.

Workflow examples use current major action tags for readability. GitHub's security guidance recommends full-length commit SHA pinning for immutable third-party action references in hardened production repositories.

# Sources used for Phase 33

- GitHub Docs: PostgreSQL service containers
- GitHub Docs: Secure use reference
- GitHub Docs: workflow syntax and GITHUB_TOKEN permissions
- GitHub Docs: OpenID Connect reference
- GitHub Docs: deployments, environments, concurrency
- Official action release pages for checkout, setup-node, upload-artifact
- Official Docker action release pages for setup-buildx, login, metadata, build-push
- pnpm/action-setup official releases

# Phase 33 verified action lines (2026-09-18)

- actions/checkout: v7 line (latest observed v7.0.1)
- actions/setup-node: v7 line (latest observed v7.0.0)
- pnpm/action-setup: v6 line (latest observed v6.0.9)
- actions/upload-artifact: v7 line (latest observed v7.0.1)
- docker/setup-buildx-action: v4 line (latest observed v4.3.0)
- docker/login-action: v4 line (latest observed v4.6.0)
- docker/metadata-action: v6 line (latest observed v6.2.0)
- docker/build-push-action: v7 line (latest observed v7.2.0)

For production hardening, pin third-party actions to verified full commit SHAs and let Dependabot maintain them. The workflow examples use major tags for readability.

# Phase 33 verification matrix

- PR lint failure blocks CI.
- Type error blocks CI.
- Unit test failure blocks CI.
- PostgreSQL integration test uses committed migrations.
- Missing migration causes integration failure rather than schema drift.
- Docker build succeeds for web and API.
- Release image is tagged with full commit SHA.
- Release workflow has `packages: write` but CI does not.
- Production deployment concurrency prevents overlapping releases.
- Production environment can require approval before secrets are exposed.
- Workflow action dependencies are reviewed/pinned for production.
- Secrets are never echoed.
- Fork PRs do not receive production secrets.
- OIDC-based cloud auth is preferred over static cloud access keys.