feat: Script Provisioning Provider extension (microsoft.azd.scripts)

[wbreza]

Description

Implements the Script Provisioning Provider extension (microsoft.azd.scripts) that enables shell script-based provisioning and teardown workflows in azd. This is a first-party extension that registers a scripts provisioning provider via gRPC.

Epic: #7733
Depends on: #7482 (provisioning provider framework)
Resolves: #7734, #7735, #7736

Architecture

The extension is a pure provisioning provider — no custom CLI commands, no MCP server. It registers via WithProvisioningProvider("scripts", factory) and implements the full azdext.ProvisioningProvider interface.

Key Components

Component	File	Purpose
Config parser	internal/provisioning/config.go	Typed config from infra.config with validation
EnvResolver	internal/provisioning/env_resolver.go	4-layer environment variable merging
ScriptExecutor	internal/provisioning/executor.go	Runs bash/pwsh scripts with merged env
OutputCollector	internal/provisioning/output_collector.go	Discovers/parses outputs.json files
Provider	internal/provisioning/provider.go	Full ProvisioningProvider implementation

User Configuration

infra:
  provider: scripts
  config:
    provision:
      - kind: sh
        run: scripts/setup.sh
        name: Setup Infrastructure
        env:
          AZURE_LOCATION: ${AZURE_LOCATION}
          RESOURCE_GROUP: rg-${AZURE_ENV_NAME}
    destroy:
      - kind: sh
        run: scripts/teardown.sh

Testing

• 25 unit tests covering config parsing, validation, env resolution, output collection, and executor
• All paths tested: happy path, error cases, edge cases, security (path traversal, absolute paths)
• Lint, spellcheck, copyright all pass

Checklist

• Extension compiles with go build
• Registers scripts provider via gRPC
• Config validation (missing run, absolute paths, path traversal, missing files, unknown kinds)
• Kind auto-inference from file extension (.sh -> sh, .ps1 -> pwsh)
• Shell -> Kind backward compatibility mapping
• Platform-specific overrides (Windows/Posix)
• 4-layer env var merging with ${EXPRESSION} substitution
• Output collection with 10MB size limit
• golangci-lint: 0 issues
• cspell: 0 issues
• All tests pass

[jongio]

6 findings from deep review. Key items:

• 2 HIGH: nondeterministic env var resolution order, no provider.go tests
• 2 MEDIUM: ContinueOnError zero-value limitation, raw stderr warning
• 2 LOW: destroy outputs discarded, missing ctx check between iterations

The extension architecture is clean - good separation of config/resolver/executor/collector. The 4-layer env resolution model is well-designed. Tests cover the individual components thoroughly.

[jongio]

Go map iteration order is nondeterministic. If two vars in the same env map reference each other (e.g., A: "${B}", B: "hello"), the result depends on which key Go happens to iterate first.

Consider sorting keys before iteration:

keys := slices.Sorted(maps.Keys(sc.Env))
for _, k := range keys {
    tmpl := sc.Env[k]
    // ...
}

Alternatively, document that cross-references within the same env map aren't supported and users should use azd environment vars (Layer 2) for shared values instead.

[jongio]

This file (223 lines) is the main integration point but has no test coverage. Config parsing, env resolution, executor, and output collector all have unit tests - but runScripts (which orchestrates error handling, output merging, and progress reporting) doesn't.

Consider adding tests that mock AzdClient and verify:

• Script execution order and progress callbacks
• Output merging across multiple scripts
• ContinueOnError behavior (continue vs stop)
• Context cancellation propagation

[jongio]

if override.ContinueOnError only triggers when the override sets it to true. Due to Go zero-value semantics, a platform override can't explicitly disable a ContinueOnError that was set in the base config.

If this is intentional (platform overrides can only add permissiveness, not remove it), a comment here would help. If not, consider using *bool to distinguish 'not set' from 'explicitly false'.

[jongio]

fmt.Fprintf(os.Stderr, ...) bypasses the extension framework's logging. The azdext package provides structured logging that integrates with azd's output handling - using it here would keep diagnostics consistent with the rest of the extension framework.

[jongio]

runScripts collects outputs from destroy scripts, but they're not wired into the result. Only invalidation keys from prior provisioning outputs are returned. If this is intentional (destroy scripts don't produce meaningful outputs), a brief comment would clarify. If destroy scripts should be able to produce outputs (e.g., for audit/logging), consider including them.

[jongio]

nit: The loop doesn't check ctx.Err() between script iterations. For long script sequences, adding an early cancellation check before each iteration would improve responsiveness:

for i, sc := range scripts {
    if err := ctx.Err(); err != nil {
        return nil, err
    }
    // ...
}