flake-status: surface flake repos the workspace walk silently misses #102

New issue

Closed

opened 2026-07-15 11:45:13 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-07-15 11:45:13 +01:00

Contributor

Context

flake-status and flake-update-cascade discover repos with workspace_collect_repos (lib/workspace.sh): a recursive walk of $WORK_DIR that stops at each git repo root. flake-status then drops any discovered repo without a root flake.lock from its output entirely (_collect_all/_collect_named write a skip marker and the render loop omits the repo), while flake-update-cascade at least prints "no flake.lock, skipping". The flake/README.md describes both tools as covering "all repos" with no caveat.

A repo newly added to the workspace therefore never appears in flake-status output when any of these hold, and nothing signals the omission or its reason:

It has flake.nix but no committed flake.lock yet (a fresh flake repo before its first lock commit) — silently absent.
Its flake lives in a subdirectory rather than the repo root — the walk stops at the repo root and only <root>/flake.lock is checked.
It has no clone under $WORK_DIR at all — e.g. allod/deploy (created 2026-07-14, currently empty): once populated, its lock pins can go stale with no signal unless every operator happens to keep a clone.

Observed 2026-07-15 while checking pins across the workspace after the recent repo additions: newly added repos were expected in flake-status --upstream output, and their absence gives no way to tell whether a repo is lock-less, nested, or simply not cloned.

Scope

One artifact in this repo: make the omission visible instead of silent.

flake-status: render repos that have flake.nix but no flake.lock as an explicit status line (e.g. (flake.nix, no flake.lock — run nix flake lock)) instead of dropping them.
lib/workspace.sh: extend discovery so a nested flake.nix/flake.lock below a repo root is found and reported as repo (subdir). Nested flakes may be status-only in the first pass; repo-root semantics stay for health warnings and cascade updates.
Keep discovery filesystem-only. Case 3 (forge repo with no local clone) requires forge-side listing that agent tokens deliberately lack (read:organization); record it as a documented limitation in flake/README.md, with any forge-backed detection left to a follow-up issue.

Validation

Workspace fixture with (a) a repo containing flake.nix and no lock, (b) a repo with a nested flake, (c) a flakeless repo: flake-status shows (a) and (b) with correct statuses and still omits (c).
Demonstrate the new status failing on sabotaged input once (removing the fixture's flake.nix removes its line).
flake-update-cascade repo set and behavior unchanged (still notices-and-skips lock-less repos); existing tests/flake/ suite passes with the shared workspace.sh change.

Out of scope

Forge API or any network-based discovery of uncloned repos.
Changing which repos flake-update-cascade is willing to update.
Workspace clone layout cleanup on any host.

## Context `flake-status` and `flake-update-cascade` discover repos with `workspace_collect_repos` (`lib/workspace.sh`): a recursive walk of `$WORK_DIR` that stops at each git repo root. `flake-status` then drops any discovered repo without a root `flake.lock` from its output entirely (`_collect_all`/`_collect_named` write a skip marker and the render loop omits the repo), while `flake-update-cascade` at least prints "no flake.lock, skipping". The `flake/README.md` describes both tools as covering "all repos" with no caveat. A repo newly added to the workspace therefore never appears in `flake-status` output when any of these hold, and nothing signals the omission or its reason: 1. It has `flake.nix` but no committed `flake.lock` yet (a fresh flake repo before its first lock commit) — silently absent. 2. Its flake lives in a subdirectory rather than the repo root — the walk stops at the repo root and only `<root>/flake.lock` is checked. 3. It has no clone under `$WORK_DIR` at all — e.g. `allod/deploy` (created 2026-07-14, currently empty): once populated, its lock pins can go stale with no signal unless every operator happens to keep a clone. Observed 2026-07-15 while checking pins across the workspace after the recent repo additions: newly added repos were expected in `flake-status --upstream` output, and their absence gives no way to tell whether a repo is lock-less, nested, or simply not cloned. ## Scope One artifact in this repo: make the omission visible instead of silent. - `flake-status`: render repos that have `flake.nix` but no `flake.lock` as an explicit status line (e.g. `(flake.nix, no flake.lock — run nix flake lock)`) instead of dropping them. - `lib/workspace.sh`: extend discovery so a nested `flake.nix`/`flake.lock` below a repo root is found and reported as `repo (subdir)`. Nested flakes may be status-only in the first pass; repo-root semantics stay for health warnings and cascade updates. - Keep discovery filesystem-only. Case 3 (forge repo with no local clone) requires forge-side listing that agent tokens deliberately lack (`read:organization`); record it as a documented limitation in `flake/README.md`, with any forge-backed detection left to a follow-up issue. ## Validation - Workspace fixture with (a) a repo containing `flake.nix` and no lock, (b) a repo with a nested flake, (c) a flakeless repo: `flake-status` shows (a) and (b) with correct statuses and still omits (c). - Demonstrate the new status failing on sabotaged input once (removing the fixture's `flake.nix` removes its line). - `flake-update-cascade` repo set and behavior unchanged (still notices-and-skips lock-less repos); existing `tests/flake/` suite passes with the shared `workspace.sh` change. ## Out of scope - Forge API or any network-based discovery of uncloned repos. - Changing which repos `flake-update-cascade` is willing to update. - Workspace clone layout cleanup on any host.