Refactor flake-status to process repos in parallel #61

New issue

Closed

opened 2026-06-22 23:35:37 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-06-22 23:35:37 +01:00

Contributor

Problem

flake-status currently walks repositories serially even though each repo's lock/health collection is independent. The README already says repos are processed in parallel, so the implementation should match that expectation.

Proposed approach

Split per-repo collection from output rendering.
Run bounded parallel workers for repo collection, writing one temp result per repo index.
Render results in the parent process in workspace order so output stays deterministic.
For --upstream, collect unique upstream URLs first, resolve them in parallel into a temp map, then render rows using that map. This preserves caching semantics without relying on an associative array inside worker subprocesses.
Keep dependencies to Bash, Git, and jq unless there is a strong reason to add another runtime.

Acceptance criteria

flake-status, flake-status <input>, and both --upstream modes keep stable workspace-order output.
Repo processing is bounded parallel by default, with an override such as FLAKE_STATUS_JOBS.
git ls-remote calls for duplicate upstream URLs are deduplicated.
Existing tests/flake-status.sh coverage passes, with added coverage for deterministic output under parallel execution if needed.

## Problem `flake-status` currently walks repositories serially even though each repo's lock/health collection is independent. The README already says repos are processed in parallel, so the implementation should match that expectation. ## Proposed approach - Split per-repo collection from output rendering. - Run bounded parallel workers for repo collection, writing one temp result per repo index. - Render results in the parent process in workspace order so output stays deterministic. - For `--upstream`, collect unique upstream URLs first, resolve them in parallel into a temp map, then render rows using that map. This preserves caching semantics without relying on an associative array inside worker subprocesses. - Keep dependencies to Bash, Git, and jq unless there is a strong reason to add another runtime. ## Acceptance criteria - `flake-status`, `flake-status <input>`, and both `--upstream` modes keep stable workspace-order output. - Repo processing is bounded parallel by default, with an override such as `FLAKE_STATUS_JOBS`. - `git ls-remote` calls for duplicate upstream URLs are deduplicated. - Existing `tests/flake-status.sh` coverage passes, with added coverage for deterministic output under parallel execution if needed.