foundry

func EntryRef ¶

func EntryRef(entry *yaml.Node) (string, bool)

EntryRef reports the $ref target of a service entry and whether the entry is $ref-backed. It recognizes the same directive key as ResolveFileRefs, so a writer and the resolver agree on which entries are file includes.

func EvaluateCondition ¶ added in v1.33.0

func EvaluateCondition(
	value string,
	getenv func(string) string,
) (bool, error)

EvaluateCondition reports whether a string condition enables a service.

It expands ${VAR} references with getenv. A nil getenv treats every variable as unset. An empty condition is enabled. After expansion, only 1, true, TRUE, True, yes, YES, and Yes enable the service; all other values disable it. Foundry ${{...}} expressions are not valid condition values. Malformed templates return an error.

func ExpandEnv ¶

func ExpandEnv(value string, mapping func(string) string) (string, error)

ExpandEnv expands ${VAR} references in value against the azd environment (via mapping) while preserving Foundry server-side ${{...}} expressions verbatim. It supports default values (${VAR:-default}) and multiple expressions, matching drone/envsubst semantics for the ${VAR} portion. On expansion error the original value is returned unchanged alongside the error.

This is the single shared expander every Foundry field, in every Foundry extension, should route through so ${VAR} and ${{...}} are handled consistently. drone/envsubst cannot parse ${{...}}, so each span is masked with a sentinel placeholder, a single Eval expands the ${VAR} references, then the spans are restored. Masking rather than splitting preserves full ${VAR:-default} semantics even when a ${{...}} expression is the default value (e.g. ${MISSING:-${{event.body}}}). A ${VAR} inside a ${{...}} span is left as-is, since the span is reserved for Foundry.

func ResolveFileRefs ¶

func ResolveFileRefs(cfg map[string]any, projectRoot string, opts ...ResolveOption) (map[string]any, error)

ResolveFileRefs resolves $ref file includes within a Foundry resource service configuration.

In the separate-services azure.yaml shape every Foundry resource is its own service entry, so each owning extension calls ResolveFileRefs on its resource's inline map: the entry keys that reach the extension over gRPC, where they arrive as a structpb.Struct decoded to map[string]any. The core ServiceConfig fields (host, the service key, uses) are stripped by core and never appear here. cfg therefore takes any of these shapes:

• A service-entry-level $ref. In azure.yaml the service entry can be authored with host: plus $ref (and optional overlay keys). Core removes ServiceConfig fields such as host before the extension sees the config, so the cfg map passed here has $ref at its top level.
• A deployment array-item $ref. Deployments stay an array on the project service, so each item in deployments may be its own $ref (e.g. ./deployments/gpt-4o.yaml).
• Any nested $ref reached while walking the entry (a $ref inside a loaded file, or a sibling value), since resolution is recursive over every map and sequence node.

projectRoot is the directory that holds azure.yaml; relative $ref targets at the top level resolve against it, and rebased project/instructions paths are anchored to it.

Any object that contains a "$ref" string is replaced by the referenced YAML or JSON file, with the object's remaining keys overlaid on top. The overlay is a shallow, top-level merge: sibling scalars, arrays, and objects each replace the loaded value wholesale. Nested $ref directives inside a loaded file resolve relative to that file's own directory, and that file's relative project, instructions, and $ref paths are rebased so the returned config has every path anchored to projectRoot in clean, forward-slash form. Inline path values authored directly in azure.yaml are left exactly as written.

$ref values that are URLs are rejected (remote includes are not supported yet); only local relative or absolute file paths are accepted. Cyclic and excessively deep include chains return an error rather than looping. $ref targets are treated as trusted input, the same trust level as azure.yaml itself.

Path keys beyond the two core owns are rebased only when named with WithPathKeys.