GloriousFlywheel Runner Dashboard Publication Decision 2026-04-16

GloriousFlywheel Runner Dashboard Publication Decision 2026-04-16

Snapshot date: 2026-04-16

Purpose

Decide whether the runner-dashboard durable publication surface should expose the derivation itself, the image path only, or both.

This note resolves the remaining publication question in #171 for the current repo state.

Companion notes:

Current Repo Facts

Direct inspection on 2026-04-16 shows:

  • packages.runner-dashboard exists as a repo-native derivation
  • packages.runner-dashboard-image exists as the Nix image path built from that derivation
  • the dashboard deployment stack consumes a plain image string via var.image
  • the active build and release workflows publish dashboard images through:
    • Docker Buildx
    • GHCR
    • Trivy vulnerability scanning
    • cosign keyless signing
  • no operator or release docs currently tell users to consume packages.runner-dashboard directly from the flake
  • no active release workflow publishes the Nix derivation itself

Decision

Current durable publication surface for the runner dashboard:

  • image path only

More specifically:

  • public/operator-facing durable publication should continue to be the GHCR dashboard image path
  • packages.runner-dashboard should remain the internal canonical build artifact and canonical Nix image-input surface
  • the repo should not currently expose the derivation itself as a standalone public publication target

Why This Is The Right Decision

1. It Matches Actual Deployment Consumption

The tofu stack consumes container images, not raw flake derivations.

2. It Matches Actual Release Authority

The only active signed and scanned release path for the dashboard is the GHCR image workflow.

3. It Avoids A Fake FlakeHub Story

The repo does not yet have:

  • a direct-consumption story for the derivation
  • a FlakeHub publication workflow
  • reconciled Nix-image versus Dockerfile-image release authority

Publishing the derivation as if it were already a public product surface would overstate the repo.

What This Means For packages.runner-dashboard

packages.runner-dashboard still matters. It is:

  • the strongest repo-native clean-derivation candidate
  • the canonical Nix image-input artifact
  • a valid internal promotion and validation surface

But it is not currently:

  • the durable public release surface
  • the operator-facing installation contract

What This Means For FlakeHub

Current answer:

  • no runner-dashboard FlakeHub publication path should be introduced yet

Reason:

  • the public release contract is image-based today
  • FlakeHub would only make sense once the repo intentionally decides to expose the derivation itself as a public discovery surface

Future Revisit Conditions

Revisit the decision only if one or more of these become true:

  • operators are expected to consume the derivation directly
  • the Nix image path becomes the active release authority
  • the repo adds a real FlakeHub publication workflow for derivations
  • the dashboard gets a durable non-image consumer story

Any such revisit should clear the explicit gate in gloriousflywheel-runner-dashboard-release-authority-change-gate-2026-04-16.md instead of treating release-authority change as implicit cleanup.

Recommendation

Recommended current wording:

  • build artifact: packages.runner-dashboard
  • canonical Nix image input: packages.runner-dashboard
  • durable public release surface: GHCR dashboard image
  • current release authority: Dockerfile + Buildx + Trivy + cosign

Exit Condition

  • the publication question for the runner dashboard has an explicit answer
  • #171 can stop treating derivation-vs-image publication as unresolved
  • future FlakeHub work is gated on an intentional change in release authority, not on guesswork

GloriousFlywheel