Submission requirements
Problem summary
ado-aw supports importing Azure DevOps variable groups through variable-groups:, but workflow front matter cannot declare ordinary pipeline YAML variables. A top-level variables: mapping is rejected as an unknown field.
Some Azure DevOps platform features and pipeline extensions require variables to exist at pipeline compile time. Without source-level support, operators must add those variables directly to each generated pipeline definition after registration. That configuration is outside the workflow source and generated lock, can drift across definitions, and may be lost when a definition is removed and recreated.
This is distinct from runtime env: values and variable-group imports: runtime environment variables may be too late for compile-time pipeline behavior, while a variable group is unnecessary for non-secret feature flags and settings.
Reproduction details
Given a minimal workflow:
---
name: Compile-time feature configuration
target: standalone
variables:
Platform.FeatureEnabled: true
Platform.Mode: strict
engine: copilot
---
Perform the configured task.
Run:
ado-aw compile workflow.md
Observed behavior:
unknown field `variables`
The current workaround is to configure each Azure DevOps pipeline definition out-of-band after ado-aw enable, for example with az pipelines variable create. The Markdown source and generated lock provide no indication that the workflow depends on those settings.
Expected behavior: non-secret pipeline variables can be declared in workflow front matter and are emitted into the generated YAML:
variables:
- name: Platform.FeatureEnabled
value: true
- name: Platform.Mode
value: strict
Proposed next step
Add a source-level variables: field for non-secret Azure DevOps pipeline variables.
Suggested acceptance criteria:
- Front matter accepts a mapping of variable names to scalar string, boolean, or numeric values.
- Compilation emits deterministic Azure DevOps YAML variables for standalone and 1ES-compatible targets.
- The compiler rejects collisions with variables it generates or reserves, with an actionable diagnostic.
- Precedence and ordering relative to
variable-groups: are documented and deterministic.
- Secret literals are rejected or explicitly unsupported; documentation directs secret values to
variable-groups:.
- Values are serialized safely without accidentally interpreting untrusted template, macro, runtime-expression, or logging-command syntax.
compile, lint, and check tests cover valid declarations, invalid names and values, reserved-name collisions, and stable lock generation.
- Documentation distinguishes compile-time pipeline variables from agent/runtime environment variables.
Submission requirements
.github/agents/ado-aw.agent.md.githubnext/ado-aw.Problem summary
ado-awsupports importing Azure DevOps variable groups throughvariable-groups:, but workflow front matter cannot declare ordinary pipeline YAML variables. A top-levelvariables:mapping is rejected as an unknown field.Some Azure DevOps platform features and pipeline extensions require variables to exist at pipeline compile time. Without source-level support, operators must add those variables directly to each generated pipeline definition after registration. That configuration is outside the workflow source and generated lock, can drift across definitions, and may be lost when a definition is removed and recreated.
This is distinct from runtime
env:values and variable-group imports: runtime environment variables may be too late for compile-time pipeline behavior, while a variable group is unnecessary for non-secret feature flags and settings.Reproduction details
Given a minimal workflow:
Run:
Observed behavior:
The current workaround is to configure each Azure DevOps pipeline definition out-of-band after
ado-aw enable, for example withaz pipelines variable create. The Markdown source and generated lock provide no indication that the workflow depends on those settings.Expected behavior: non-secret pipeline variables can be declared in workflow front matter and are emitted into the generated YAML:
Proposed next step
Add a source-level
variables:field for non-secret Azure DevOps pipeline variables.Suggested acceptance criteria:
variable-groups:are documented and deterministic.variable-groups:.compile,lint, andchecktests cover valid declarations, invalid names and values, reserved-name collisions, and stable lock generation.