Bug: Conditional scope statement stopped working

[AlexanderSehr]

Bicep version Bicep CLI version 0.30.23

Describe the bug I noticed today that conditional scope statements (e.g., for nested deployments) started failing in any AVM template that uses them. The issue surfaces as follows:

A previously valid deployment like

param storageAccountResourceId string = ''

module storageAccount_sbdc_rbac 'modules/nested_storageRoleAssignment.bicep' = if (isManagedIdentityInUse && !empty(storageAccountResourceId)) {
  name: '${server.name}-stau-rbac'
  scope: !empty(storageAccountResourceId)
    ? resourceGroup(split(storageAccountResourceId!, '/')[2], split(storageAccountResourceId!, '/')[4])
    : resourceGroup()
   (...)

now shows the error

The property "scope" expected a value of type "resourceGroup" but the provided value is of type "{ id: string, location: string, managedBy: string, name: string, properties: properties, tags: Tags, type: string }".bicep[BCP036](https://aka.ms/bicep/core-diagnostics#BCP036)

Which implies that the return value of the resourceGroup() function is not detected as a proper resource reference, but instead the object that a resource group is (hene the type description).

Now the fun part is the following: The resourceGroup() function works absolutely fine - as long as you do not reference a parameter (a variable is fine). So for example this works like a charm:

module storageAccount_sbdc_rbac 'modules/nested_storageRoleAssignment.bicep' = if (isManagedIdentityInUse && !empty(storageAccountResourceId)) {
  name: '${server.name}-stau-rbac'
  scope: !empty('heyThere')
    ? resourceGroup(split(storageAccountResourceId!, '/')[2], split(storageAccountResourceId!, '/')[4])
    : resourceGroup()
   (...)

or

module storageAccount_sbdc_rbac 'modules/nested_storageRoleAssignment.bicep' = if (isManagedIdentityInUse && !empty(storageAccountResourceId)) {
  name: '${server.name}-stau-rbac'
  scope: true == true
    ? resourceGroup(split(storageAccountResourceId!, '/')[2], split(storageAccountResourceId!, '/')[4])
    : resourceGroup()
   (...)

or

var storageAccountResourceId = 'myId'
module storageAccount_sbdc_rbac 'modules/nested_storageRoleAssignment.bicep' = if (isManagedIdentityInUse && !empty(storageAccountResourceId)) {
  name: '${server.name}-stau-rbac'
  scope: !empty(storageAccountResourceId)
    ? resourceGroup(split(storageAccountResourceId!, '/')[2], split(storageAccountResourceId!, '/')[4])
    : resourceGroup()
   (...)

So it seems that just the reference of a parameter changes the way the resourceGroup() function behaves / is interpreted and breaks the template. This is, naturally, quite unfortunate, as we deploy quite a sizable amount of modules into different scopes based on input parameters.

To Reproduce Steps to reproduce the behavior:

Just copy the following snippet into a Bicep file:

param someParam string = ''

module someDeployment 'br/public:avm/res/key-vault/vault:0.10.2' = {
  name: 'someDeploymentName'
  params: {
    name: 'iAmUnique'
  }
  scope: !empty(someParam) ? resourceGroup(someParam) : resourceGroup()
}

[slavizh]

+1

[slavizh]

@jeskew this is also bug in the new Bicep version.

[slavizh]

@AlexanderSehr did you added the wrong Bicep CLI version in the description of the issue?

[AlexanderSehr]

@AlexanderSehr did you added the wrong Bicep CLI version in the description of the issue?

Hey @slavizh, in fact, I did not. Locally I was runnning 0.30.23 and on the pipeline agents the new 0.31.34. It did fail in both (and I don't know why as you'd think it's a bug introduced via a new version). Not that it should matter much, but the az bicep version also already failed with version 0.30.23.

[slavizh]

@AlexanderSehr strange as I have code similar to the one you have reported and it is failing only on 31.34. This failure is seen even in VSC before deployment. As soon as I downgrade to 30.23 I do not see the issues and the code is working fine.

[alex-frankel]

@AlexanderSehr - can you try explicitly setting the version in your pipeline to 0.30 with az bicep install -v "0.30.23"?

I'm wondering if there is possibly an issue on the local machine where bicep is falsely telling you it is using 0.30, but is actually using 0.31.

[AlexanderSehr]

@AlexanderSehr - can you try explicitly setting the version in your pipeline to 0.30 with az bicep install -v "0.30.23"?

I'm wondering if there is possibly an issue on the local machine where bicep is falsely telling you it is using 0.30, but is actually using 0.31.

Hey @alex-frankel, that did, in fact, work: https://github.com/AlexanderSehr/bicep-registry-modules/actions/runs/11783023645

I guess my local installation wanders in mysterious ways...

[glen-olsen-visma-com]

+1 This is breaking all our production pipelines at the moment since 0.31.34. Running through Azure Pipelines using task AzureResourceManagerTemplateDeployment@3

[peterbud]

@AlexanderSehr : what is now the plan for the bicep-registry-modules repo? Are you going to pin the bicep version in the pipeline to the last working version, until this bug will be fixed?

[AlexanderSehr]

Hey @peterbud, that depends a bit. If the PG releases a new version with @jeskew's fix that rather sooner than later (e.g., tomorrow), then we may be fine. If not - than we can hardcode the version in the CI, e.g., tomorrow. @alex-frankel & @jeskew, can you share you thoughts? :)