User Impact
When using an environment override file (e.g., configuration.prod.yaml) with workspace-scoped overrides like this:
workspaces:
- name: my-workspace
properties:
description: "Production workspace"
apis:
- name: my-api
properties:
serviceUrl: "https://prod.example.com"
backends:
- name: my-backend
properties:
url: "https://prod-backend.example.com"
The CLI applies overrides to the workspace container itself (the properties on the workspace entry), but silently ignores all nested child overrides (apis, backends, loggers, etc. within the workspace). Customers migrating from the APIOps Toolkit who use workspace-scoped overrides will find that their workspace child resources are published with dev/staging values instead of the expected production values.
Technical Details
The APIOps Toolkit resolves overrides using a parent chain — when publishing a resource scoped to a workspace (e.g., workspace API my-api in workspace my-workspace), it walks the override config: workspaces → my-workspace → apis → my-api → properties.
The CLI currently:
- Parses workspace child override sections correctly in
config-loader.ts (nested entries under workspaces are stored in OverrideEntry.children)
- Never applies them —
override-merger.ts doesn't check descriptor.workspace to determine if a resource is workspace-scoped, and doesn't look into workspace entry children for the override
Expected Behavior
When publishing a workspace-scoped resource, the override merger should:
- Check if the resource's descriptor has a
workspace field set
- If so, look up the workspace in the
workspaces override section
- Navigate into that workspace's children to find the appropriate override for the child resource type and name
- Apply the override properties via deep merge
This should work for all workspace child types (apis, backends, diagnostics, groups, loggers, namedValues, policyFragments, products, subscriptions, tags, versionSets) including nested API sub-resources (workspace api → diagnostics, operations, policies, releases).
Related
This was identified during the filter/override format alignment work in #114 / PR #115.
User Impact
When using an environment override file (e.g.,
configuration.prod.yaml) with workspace-scoped overrides like this:The CLI applies overrides to the workspace container itself (the
propertieson the workspace entry), but silently ignores all nested child overrides (apis, backends, loggers, etc. within the workspace). Customers migrating from the APIOps Toolkit who use workspace-scoped overrides will find that their workspace child resources are published with dev/staging values instead of the expected production values.Technical Details
The APIOps Toolkit resolves overrides using a parent chain — when publishing a resource scoped to a workspace (e.g., workspace API
my-apiin workspacemy-workspace), it walks the override config:workspaces → my-workspace → apis → my-api → properties.The CLI currently:
config-loader.ts(nested entries under workspaces are stored inOverrideEntry.children)override-merger.tsdoesn't checkdescriptor.workspaceto determine if a resource is workspace-scoped, and doesn't look into workspace entry children for the overrideExpected Behavior
When publishing a workspace-scoped resource, the override merger should:
workspacefield setworkspacesoverride sectionThis should work for all workspace child types (apis, backends, diagnostics, groups, loggers, namedValues, policyFragments, products, subscriptions, tags, versionSets) including nested API sub-resources (workspace api → diagnostics, operations, policies, releases).
Related
This was identified during the filter/override format alignment work in #114 / PR #115.