Move the azd ${VAR} reference scanner into pkg/foundry
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
Follow-up from review on #9367.
## Context
`FindEnvReferences` / `ValidateEnvReferences` are the single scanner for azd `${VAR}` references in a Foundry value. They answer, for a given string, exactly which occurrences `foundry.ExpandEnv` will act on: `$$` escapes are collapsed, `${{...}}` spans are reserved (detected by substituting a per-occurrence probe and letting `ExpandEnv` report which probes it left alone), balanced `:-` defaults are walked, and anything outside `${VAR}` / `${VAR:-default}` / `$${VAR}` / `${{...}}` is rejected so the scan stays complete against drone/envsubst's wider grammar.
Three consumers need that answer:
- `azure.ai.agents/internal/cmd` — init prompting and the generated service env block
- `azure.ai.agents/internal/synthesis` — `resolveVars`' unresolved-variable guard
- `azure.ai.projects/internal/synthesis` — same code, byte-identical copy
## Problem
The natural home is `cli/azd/pkg/foundry`, next to `ExpandEnv`, whose behavior it models. That was the reviewer's ask on #9367.
It cannot go there yet. Both extensions consume azd core at a pinned release (`github.com/azure/azure-dev/cli/azd v1.28.0`, with core currently at 1.30.0-beta.1) and neither carries a `replace`, so new `pkg/foundry` API is not visible to them until core ships and both `go.mod` files are bumped — the two-PR rule in `cli/azd/AGENTS.md`.
#9367 therefore homed it in `internal/synthesis`, which is the one import path the two byte-identical synthesizer copies and `internal/cmd` can all spell identically (`parity_test.go` compares the non-test `.go` files byte for byte, so a module-qualified import such as `azureaiagent/internal/pkg/envrefs` would break parity). That gives one implementation today, in a package whose doc comment is about ARM synthesis.
## Proposed work
1. Move `envrefs.go` to `cli/azd/pkg/foundry` (exported as `foundry.FindEnvReferences` / `foundry.ValidateEnvReferences`), with its tests.
2. Ship a core release.
3. `go get github.com/azure/azure-dev/cli/azd && go mod tidy` in both extensions, delete both `internal/synthesis/envrefs.go` copies and the `internal/cmd/env_refs.go` adapter, and point all callers at `pkg/foundry`.
Step 3 also removes the layering wart where `internal/cmd` imports `internal/synthesis` purely for the scanner, which matters when `internal/synthesis` leaves `azure.ai.agents` at the end of the staged ownership migration.
Contributor guide
Assessment
This issue has not been assessed yet.