GloriousFlywheel ARC CI Input Contract 2026-04-15

GloriousFlywheel ARC CI Input Contract 2026-04-15

Snapshot date: 2026-04-15

Purpose

Capture the CI-side contract that is replacing tofu/stacks/arc-runners/legacy-civo.tfvars.

This note is scoped narrowly to the ARC deploy workflow and the arc-runners stack. It is the next decision surface after the generic backend plumbing and secret-backed workflow inputs were put in place.

Companion notes:

Current Repo Facts

Direct inspection on 2026-04-15 shows:

  • .github/workflows/deploy-arc-runners.yml now prefers explicit KUBECONFIG_B64, KUBE_CONTEXT, and TOFU_BACKEND_CONFIG inputs
  • that workflow now plans against tofu/stacks/arc-runners/dev-policy.tfvars
  • that workflow now appends tofu/stacks/arc-runners/dev-extra-runner-sets.tfvars when present
  • that workflow can now append org-specific additive or overriding policy from the optional TOFU_EXTRA_POLICY_TFVARS secret
  • legacy-civo.tfvars is no longer the primary workflow policy input
  • legacy-civo.tfvars carried more than just cluster connectivity, which is why the split was needed

Current committed dev-policy.tfvars payload:

  • github_config_url = "https://github.com/tinyland-inc"
  • github_config_secret = "github-app-secret"
  • runner policy choices:
    • Docker runner enabled
    • DinD runner enabled
    • Longhorn enabled
    • CPU, memory, and ephemeral-storage tuning

Current committed additive dev-extra-runner-sets.tfvars payload:

  • extra runner set linux-xr-docker

Deprecated legacy-civo.tfvars reference payload:

  • cluster_context = "tinyland-civo-dev"
  • github_config_url = "https://github.com/tinyland-inc"
  • github_config_secret = "github-app-secret"
  • runner policy choices:
    • Docker runner enabled
    • DinD runner enabled
    • Longhorn enabled
    • CPU, memory, and ephemeral-storage tuning
    • extra runner set linux-xr-docker

What The Stack Actually Requires

From tofu/stacks/arc-runners/variables.tf:

  • cluster_context is required
  • github_config_url is required
  • many other values have defaults and are optional from the stack’s point of view

That means the CI contract is not just “give the workflow a kubeconfig.” Replacing legacy-civo.tfvars cleanly requires deciding which non-default policy values should continue to define the dev ARC environment.

Contract Split

The clean split is:

1. Connectivity And Authority Inputs

These should stay workflow-secret or backend-authority inputs:

  • KUBECONFIG_B64
  • KUBE_CONTEXT
  • TOFU_BACKEND_CONFIG

These define how CI reaches the cluster and state backend. They should not carry runner topology or resource policy.

2. Environment Policy Inputs

These are the values that define what the dev ARC environment actually deploys:

  • github_config_url
  • github_config_secret if not using the default
  • deploy_docker_runner
  • deploy_dind_runner
  • deploy_longhorn
  • resource and storage sizing
  • extra_runner_sets

These now belong in explicit policy sources instead of staying embedded in a mixed compatibility tfvars file.

Current precedence inside the compatibility workflow:

  1. committed baseline policy: dev-policy.tfvars
  2. committed additive policy: dev-extra-runner-sets.tfvars when present
  3. optional org-specific additive or overriding policy: TOFU_EXTRA_POLICY_TFVARS

Practical Options

Option A: Commit A Real dev.tfvars

What it means:

  • create a first-class tofu/stacks/arc-runners/dev.tfvars
  • keep only secrets and backend/kubeconfig material outside the repo

Why it fits:

  • most current values in legacy-civo.tfvars are not secrets
  • it makes the intended dev runner shape visible and reviewable

Main cost:

  • it turns the current compatibility policy into explicit product truth, so the values need to be clean enough to own publicly

Option B: Inject Policy Tfvars Through CI

What it means:

  • keep policy outside the repo as a secret-backed or generated tfvars file

Why it is weaker:

  • it preserves ambiguity about what the dev ARC environment actually is
  • it makes future repo truthing harder because policy remains external

Option C: Split Minimal Repo Truth From Extra Runner Sets

What it means:

  • commit a minimal dev.tfvars for the base ARC environment
  • keep more volatile extras such as extra_runner_sets external for a while

Why it may be the best transition:

  • it removes the hidden baseline while preserving flexibility for cross-repo experimentation

Recommendation

Recommended next step:

  • continue with Option C, which is now executed more explicitly in-repo

Reasoning:

  • the repo now owns a committed baseline ARC policy file through dev-policy.tfvars
  • the repo now keeps extra runner-set policy separate through dev-extra-runner-sets.tfvars
  • connectivity, kubeconfig, and backend secrets should stay external
  • volatile or organization-specific extra scale sets can remain separate for a short transition if needed

Remaining decision:

  • additive-runner-set governance is now explicit in gloriousflywheel-arc-additive-policy-governance-2026-04-15.md
  • the remaining work is to apply that governance consistently as more installation-specific or product-owned runner sets appear

Exit Condition

  • legacy-civo.tfvars is no longer required to express the intended dev ARC environment in the main workflow path
  • the workflow consumes explicit authority inputs plus explicit baseline and additive policy sources instead of a mixed compatibility file

GloriousFlywheel