Repository navigation
Emit declared build parameters into build-graph.json #499
Description
Problem
build-graph.json (the editor-tooling contract in BuildGraphUtility) carries only targets. The build's [Parameter]/[Secret] members — e.g. NuGetApiKey on IPublish, the set dotnet fallout --help lists — never reach the VS Code extension, so it can't surface them.
Outcome
Additive parameters[] in build-graph.json, projected from the build's declared parameters. Schema stays v1 (new field is backward-compatible):
{ "name": "NuGetApiKey", "secret": true, "description": "…", "declaredIn": "IPublish" }Acceptance criteria
- All declared
[Parameter]members are projected, including inherited component params (IPublish, etc.) — matching--help's set. [Secret]members flaggedsecret: true.- Fields:
name,secret,description,declaredIn. SchemaVersionunchanged (additive); existing consumers unaffected.BuildGraphUtilitySpecsupdated to cover the projection.
Context: [ADR-0009] run-config discussion; feeds the extension issue below.
Activity
Add Build/Deployment/Run Configuration views and an Explorer dock
ChrisonSimtian commentedon Aug 22, 2026
Flagging a downstream consumer, since nothing here mentioned one: Fallout-build/Fallout.Extensions.VSCode#1 is blocked on this and can't start until
parameters[]exists.The VS Code extension's Run Configuration view already collects parameters and secrets — values become
--name valueargs, secrets go toSecretStorageand are passed as environment variables. But it's free-form: you hand-type every name, so a declared member likeNuGetApiKey([Parameter][Secret]) never shows up and the Secrets section reads as empty.What the extension needs from the graph, to pre-populate rather than guess:
[Secret], so it routes toSecretStorage+ env var instead of an argument, and renders as "not set" rather than blankScraping
dotnet fallout --helpwas considered and rejected: it would make the extension a second source of truth for the parameter surface, which drifts the moment the framework changes its output.Consumer-side detail worth knowing: the extension treats
parameters[]as optional and falls back to today's free-form behaviour when absent, so shipping this is not a breaking change for older graphs — no coordination needed beyond the field appearing.