githubnext / githubnext/ado-aw

[agent-issue]: support declarative Azure DevOps pipeline variables in workflow source

Offen
#2,012 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
enhancement rust
Vorherrschende Sprache
Rust
Sterne
23
Forks
8
Ø Merge
4 T. 10 Std.
Gemergte PRs (30 T.)
24

Beschreibung

### Submission requirements

- [x] I generated this issue with an agent that used `.github/agents/ado-aw.agent.md`.
- [x] I reviewed the generated issue and confirm it is being filed directly in `githubnext/ado-aw`.

### 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:

```markdown
---
name: Compile-time feature configuration
target: standalone
variables:
Platform.FeatureEnabled: true
Platform.Mode: strict
engine: copilot
---

Perform the configured task.
```

Run:

```bash
ado-aw compile workflow.md
```

Observed behavior:

```text
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:

```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:

1. Front matter accepts a mapping of variable names to scalar string, boolean, or numeric values.
2. Compilation emits deterministic Azure DevOps YAML variables for standalone and 1ES-compatible targets.
3. The compiler rejects collisions with variables it generates or reserves, with an actionable diagnostic.
4. Precedence and ordering relative to `variable-groups:` are documented and deterministic.
5. Secret literals are rejected or explicitly unsupported; documentation directs secret values to `variable-groups:`.
6. Values are serialized safely without accidentally interpreting untrusted template, macro, runtime-expression, or logging-command syntax.
7. `compile`, `lint`, and `check` tests cover valid declarations, invalid names and values, reserved-name collisions, and stable lock generation.
8. Documentation distinguishes compile-time pipeline variables from agent/runtime environment variables.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Rechercherichtung

Es werden keine Quelldateien genannt. Beginne damit, die für `ado-aw compile workflow.md` verwendeten Pfade zur Verarbeitung des Front-Matters und zur Kompilierung nachzuverfolgen, und vergleiche sie dann mit der bestehenden Behandlung von `variable-groups:`. Erledigt ist die Aufgabe, wenn gültige nicht geheime skalare Zuordnungen deterministische Variablen für Standalone- und 1ES-Ziele erzeugen, während `compile`, `lint` und `check` Kollisionen, ungültige Werte, Sortierung und die Lock-Stabilität abdecken.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
azure, rust, yaml
Bereich
build-system, ci-cd, devops, documentation, testing-qa
Issue-Typ
Feature
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Aktiv
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
45/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.