Add experimental feature to enable runtime values in tags and SKU

[tsmallig33]

Description

Add experimental feature to enable runtime values in tags and sku

Example Usage

resource example 'Microsoft...' = {
  name: 'example'
  location: resourceGroup().location
  sku: {
    name: this.existingResource().?sku.name ?? 'Standard'
  }
  tags: this.existingResource().?tags ?? {}
}

Checklist

• I have read and adhere to the contribution guide.

Microsoft Reviewers: Open in CodeFlow

[github-actions]

Test this change out locally with the following install scripts (Action run 29768276323)

VSCode

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 29768276323

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 29768276323"

Azure CLI

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-cli.sh) --run-id 29768276323

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 29768276323"

[Copilot]

Pull request overview

This PR introduces a new experimental feature flag (runtimeValuesInTagsAndSku) that relaxes deploy-time-constant (DTC) restrictions so runtime values (e.g., this.existingResource()) can be used in tags and sku assignments for Azure resources. This is implemented in the Bicep.Core DTC validation pipeline, surfaced through configuration/schema, documented, and covered by unit tests.

Changes:

• Add runtimeValuesInTagsAndSku to experimental feature configuration, schema, and documentation.
• Relax DTC validation for tags and sku object properties when the feature is enabled.
• Add unit tests validating success/failure behavior with the feature enabled/disabled.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/vscode-bicep/schemas/bicepconfig.schema.json	Adds schema support for the new experimental flag.
src/Bicep.Core/TypeSystem/Providers/Az/AzResourceTypeProvider.cs	Centralizes tags/sku property names and uses them in the DTC property set.
src/Bicep.Core/TypeSystem/DeployTimeConstantContainerVisitor.cs	Skips DTC container collection for tags/sku when the feature is enabled.
src/Bicep.Core/Features/RecordBasedFeatureProvider.cs	Exposes the new feature flag via record-backed provider.
src/Bicep.Core/Features/IFeatureProvider.cs	Adds the feature flag and metadata entry.
src/Bicep.Core/Features/FeatureProvider.cs	Wires the feature flag to configuration.
src/Bicep.Core/Configuration/ExperimentalFeaturesEnabled.cs	Adds the new experimental flag to the configuration record + defaults.
src/Bicep.Core.UnitTests/Semantics/Namespaces/ThisNamespaceTests.cs	Adds compilation tests for runtime values in tags and sku.
src/Bicep.Core.UnitTests/Features/OverriddenFeatureProvider.cs	Propagates the override for the new feature flag in tests.
src/Bicep.Core.UnitTests/Features/FeatureProviderOverrides.cs	Adds an override property for the new feature flag.
src/Bicep.Core.UnitTests/Configuration/ConfigurationManagerTests.cs	Updates built-in configuration expectations to include the new flag.
docs/experimental-features.md	Documents the new experimental feature and usage.

[anthony-c-martin]

Is it possible to avoid setting this type property in the first place, rather than adding exceptions in the validation code?

One example of why this is problematic / difficult to do here - you're just looking for any property named "sku" or "tags", without checking where exactly it appears - whereas in reality, this should only affect az resource types, and for properties declared as top-level resource properties.

[tsmallig33]

Yes, thanks. Moved the check to AzResourceTypeProvider where the DTC flag is applied. I added a PermitRuntimeValuesInTagsAndSku flag since I didn't see a good way to access FeatureProvider from inside AzResourceTypeProvider.