Skip to content

Add generic config property bag to HookConfig #7653

@wbreza

Description

@wbreza

Background & Motivation

Different hook executor types (Python, JS, TS, .NET) have unique configuration needs beyond the shared run, dir, kind, and continueOnError fields. Today there's no mechanism for users to pass executor-specific settings in azure.yaml.

azd already uses a config property bag pattern in several places:

  • state.RemoteConfigbackend discriminator + Config map[string]any for backend-specific settings
  • platform.Configtype discriminator + Config map[string]any for platform-specific settings
  • ServiceConfigConfig map[string]any for service-target-specific settings (e.g., packageManager for Node.js)

Proposal

Add a Config map[string]any field to HookConfig in pkg/ext/models.go, discriminated by the existing Kind field. Each executor receives the raw config bag and can unmarshal it into a strongly-typed struct.

Example azure.yaml

hooks:
  postprovision:
    run: ./hooks/seed-database.cs
    kind: dotnet
    config:
      configuration: Release
      framework: net10.0
hooks:
  postprovision:
    run: ./hooks/setup.py
    kind: python
    config:
      virtualEnvName: .venv

Implementation Approach

  1. Add Config map[string]any to HookConfig (yaml tag: config,omitempty)
  2. Extend ExecutionContext to carry the raw config bag to executors
  3. Each executor optionally unmarshals the config bag into a typed struct (e.g., dotnetHookConfig{Configuration string, Framework string}) using mapstructure or encoding/json re-marshal
  4. Update the JSON schema (azure.yaml.json) — use a oneOf discriminated on kind to validate per-executor config shapes
  5. Update docs/language-hooks.md with per-executor config options

Example Executor Config Types

// dotnet executor
type dotnetHookConfig struct {
    Configuration string `json:"configuration"` // Debug, Release
    Framework     string `json:"framework"`     // net8.0, net10.0
}

// python executor
type pythonHookConfig struct {
    VirtualEnvName string `json:"virtualEnvName"` // override venv dir name
}

Out of Scope

  • Config validation at YAML load time (executors validate their own config)
  • Config inheritance from project-level to service-level hooks

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions