Pipeline Overview

Pipeline Overview

GloriousFlywheel no longer uses one universal sequential pipeline that plans and deploys every stack in order.

Current main is GitHub-first and is organized around workflow families.

Current Workflow Families

Validation and policy

  • Validate checks config, OpenTofu modules and stacks, docs, and app surfaces
  • Secret Detection scans the repo for committed secrets

These are broad repo-validation workflows, not deployment workflows. They are also first-party dogfood gates: they run on shared tinyland-* lanes, not GitHub-hosted runners, so runner/cache regression is visible instead of hidden behind a hosted fallback.

Shared-runner proof

  • Platform Proof proves the shared runner contract on the live runner labels
  • Source Bazel Proof proves the source-repo Bazel cache-first package path
  • Test ARC Runners Soak is the manual bounded soak surface for runner lanes
  • Runner Benchmarks is the manual benchmark surface

These workflows exist to prove the platform contract, not to replace operator runbooks.

Build and publication

  • Build Container Images builds and publishes internal container artifacts
  • Publish to FlakeHub publishes flake outputs for rolling or tagged releases
  • Release cuts GitHub releases for version tags
  • Mirror Docker Hub Images to GHCR maintains bounded mirrored base images

Deployment

  • Deploy ARC Runners is the only stack-specific automated deploy workflow on current main
  • Deploy Docs publishes the docs site

The repo does not currently auto-apply every infrastructure stack on every merge.

Status and reporting

  • Tranche Proof Status renders the bounded tranche proof bundle from repository workflow state on the shared dogfood runner path

Trigger Model

Pull requests

Pull requests primarily run:

  • validation and proof workflows
  • a bounded ARC plan when ARC-related paths change

They do not run a universal apply path.

Pushes to main

Pushes to main run:

  • validation and proof workflows
  • path-scoped build, publish, and deploy workflows
  • the ARC apply workflow when ARC-related paths change

Scheduled or manual flows

Scheduled or manual execution exists for:

  • Source Bazel Proof
  • Tranche Proof Status
  • Runner Benchmarks
  • Test ARC Runners Soak
  • selected deploy and publish paths

What This Means

Current repo truth:

  • there is no single five-stage Validate -> Build -> Plan -> Deploy -> Verify pipeline for the whole platform
  • proof, deployment, publication, and reporting are separate workflow families
  • only the ARC stack currently has an automated apply workflow on main
  • the remaining stacks still rely on bounded internal operator deployment paths

GloriousFlywheel