Skip to content

Emit per-target status in build-graph.json and re-emit on transitions - #529

Open
ChrisonSimtian wants to merge 1 commit into
Fallout-build:mainfrom
ChrisonSimtian:feature/build-graph-status
Open

Emit per-target status in build-graph.json and re-emit on transitions#529
ChrisonSimtian wants to merge 1 commit into
Fallout-build:mainfrom
ChrisonSimtian:feature/build-graph-status

Conversation

@ChrisonSimtian

Copy link
Copy Markdown
Collaborator

The producer half of the live run graph: build-graph.json now carries per-target status and is re-written on every target transition, so editor tooling (the VS Code extension) can watch the file and animate a run live — queued → running → succeeded/failed.

  • BuildGraphUtility projects ExecutionStatus onto the control's vocabulary (scheduled→queued, running, succeeded, failed/aborted→failed, skipped). Neutral states (none/notrun/collective) emit null, so a structural or --plan snapshot stays unstyled — only a real run paints the nodes.
  • SerializeBuildGraphAttribute captures the targets at init and now also implements IOnTargetRunning/Succeeded/Failed/Skipped, re-emitting on each (the executor updates target.Status in place before firing the hook). Best-effort, locked write — never fails the build.

Additive / non-breaking: a consumer predating the field ignores the extra key, so it stays schema v1 (guarded by a test).

Verified: unit tests cover the status projection (scheduled→queued, neutral→null, etc.); dogfooding ./build.ps1 Clean emits build-graph.json with Clean=succeeded and everything else null.

Independent of the graph-control PRs — it just widens the JSON contract. The consumer side (the control's mountLive + the extension's file-watcher) animates this automatically.

Adds a `status` field to each target in build-graph.json and re-writes the file
on every target state transition, so editor tooling watching it can animate a
run live (queued → running → succeeded/failed) — the producer half of the live
run graph.

- BuildGraphUtility projects ExecutionStatus onto the graph control's vocabulary
  (scheduled→queued, running, succeeded, failed/aborted→failed, skipped). Neutral
  states (none/notrun/collective) emit null, so a structural or --plan snapshot
  stays unstyled and only a real run paints the nodes.
- SerializeBuildGraphAttribute captures the targets at init and now also handles
  IOnTargetRunning/Succeeded/Failed/Skipped, re-emitting the graph (with the
  executor's in-place status updates) on each. Still best-effort — a write failure
  never fails the build; the write is locked.
- Additive and backwards-compatible: a consumer that predates the field ignores
  the extra key, so it stays schema v1 (guarded by a test).

Verified: unit tests cover the status projection; dogfooding `./build.ps1 Clean`
emits build-graph.json with Clean=succeeded and the rest null.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ChrisonSimtian ChrisonSimtian added enhancement New feature or request target/vCurrent Targets the current version labels Jul 21, 2026
@ChrisonSimtian
ChrisonSimtian marked this pull request as ready for review July 26, 2026 10:41
@ChrisonSimtian
ChrisonSimtian requested a review from a team as a code owner July 26, 2026 10:41
@ChrisonSimtian ChrisonSimtian added this to the vscode extension milestone Jul 26, 2026
@ChrisonSimtian ChrisonSimtian added target/vNext Targets the next calendar-version target/vCurrent Targets the current version and removed target/vCurrent Targets the current version target/vNext Targets the next calendar-version labels Aug 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request target/vCurrent Targets the current version

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant