support "naive" nested deployments

[alex-frankel]

for 0.1, want to verify that we have at least a way to do this, even if it's not great

[alex-frankel]

Attempted this and hit an issue with the $schema property which is required in a template. Here's the code:

resource nested 'microsoft.resources/deployments@2020-06-01' = {
  name: 'nested01'
  properties: {
    mode: 'Incremental'
    resourceGroup: 'giants-deep'
    template: {
      $schema: 'https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#'
      contentVersion: '1.0.0.0'
      resources: [
        {
          name: 'storage001'
          type: 'Microsoft.Storage/storageAccounts'
          apiVersion: '2019-06-01'
          sku: {
            name: 'Standard_LRS'
          }
          kind: 'StorageV2'
          location: 'eastus'
        }
      ]
    }
  }
}

Here's the error:

[majastrz]

Yeah, properties only support identifier characters right now and $ isn't one. I think we have 2 questions here:

• Should $ be allowed in identifier names? I don't have a huge objection against it.
• We need an alternative syntax for object property names that also allows characters that are not allowed in identifiers. Something like this likely:

variable foo = {
  'this property has spaces in its name for some reason': true
}

For situations like user-assigned identities, we would also need to allow string interpolation. (The IL allows expressions in property names.)

[alex-frankel]

Feels like it's ok to just allow it. TypeScript seems to allow it.

You start the property name with ' and end it with ```, what that intentional? I think I'm fine with either one.

[bterlson]

JS allows $ and _ to start identifiers, which are common additions. UAX-31 has a table of optional start, medial, and continue identifier characters you can consider!

[majastrz]

@alex-frankel Fixed the quote in my comment.

[alex-frankel]

This looks good to me

[filizt]

The top level resource group name and subscription properties show error in nested deployments. See image below.

Error: The property 'resourceGroup' is not allowed on objects of type 'Microsoft.Resources/deployments@2020-06-01'.bicep(BCP037)

[anthony-c-martin]

We're now using swagger-generated types, but looks like we're still missing these properties:
https://github.com/Azure/bicep-types-az/blob/main/generated/docs/microsoft.resources/2020-06-01/types.md#microsoftresourcesdeployments

I'll need to look into whether this is a problem with our swagger definitions or our type generator...

[SimonWahlin]

I'm trying to create a nested deployment using 'inner' as expressionEvaluationOptions and sending params from my parent template to my nested template.

Using the latest code in main, creating a nested template seems to work, but I cannot figure out a way to reference my inner parameters inside my nested template.

This is what I got so far:

resource additionalAppSettings 'Microsoft.Resources/deployments@2020-06-01' = {
    name: 'additionalAppSettings'
    properties: {
        expressionEvaluationOptions: {
            scope: 'inner'
        }
        mode: 'Incremental'
        template: {
            '$schema': 'https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#'
            contentVersion: '1.0.0.0'
            parameters: {
                existingAppSettings: {
                    type: 'object'
                    defaultValue: {}
                }
                newAppSettings: {
                    type: 'object'
                    defaultValue: {}
                }
                functionAppName: {
                    type: 'string'
                }
            }
            resources: [
                {
                    type: 'Microsoft.Web/sites/config'
                    name: '[concat(parameters(functionAppName),\'/appsettings\')]'
                    apiVersion: '2020-06-01'
                    properties: '[union(parameters(\'existingAppSettings\'),parameters(\'newAppSettings\'))]'
                }
            ]
            outputs: {}
        }
        parameters: {
            existingAppSettings: {
                value: functionAppSettings
            }
            newAppSettings: {
                value: appSettings
            }
            functionAppName: {
                value: functionApp.name
            }
        }
    }
}

My problem is on these two lines:

name: '[concat(parameters(functionAppName),\'/appsettings\')]'
properties: '[union(parameters(\'existingAppSettings\'),parameters(\'newAppSettings\'))]'

Here I've tried using "native" ARM language, which is the closest I've gotten, but bicep then escapes the first '[' with an extra '[' resulting in an ARM template that looks like this:

"name": "[[concat(parameters(functionAppName),'/appsettings')]",

I've also tried using a more bicep-like approach with something similar to:

name: '${parameters('functionAppName')}/appsettings'

Then I get the error Error BCP057: The name "parameters" does not exist in the current context.

Is there a way to write a string that gets directly passed on to the ARM template without being escaped?
This would be a nice feature for anytime I want to do something that bicep hasn't implemented yet.

[alex-frankel]

Is there a way to write a string that gets directly passed on to the ARM template without being escaped?

Not today. We intentionally are blocking this to expose specific cases where we need this :) We will have to take a look to see if we should revoke this.

However, in this particular case, you can use the new modules capability, which will create a nested deployment using scope: inner. You will need to install the latest version of the CLI and VS Code extension from here as it is not officially released:
https://github.com/Azure/bicep/actions/runs/320112126

Instructions on installing these "nightly" builds here: https://github.com/Azure/bicep/blob/main/docs/installing-nightly.md

[SimonWahlin]

Thank you @alex-frankel!

I will give modules a try tonight.

[alex-frankel]

Great! Here is the spec: https://github.com/Azure/bicep/blob/main/docs/spec/modules.md

[SimonWahlin]

Works like a charm!

Had to use reference() to avoid getting api-version and 'Full' since appsettings don't support GET methods.

module additionalAppSettings './additionalAppSettings.bicep' = {
    name: 'additionalAppSettings'
    params: {
        existingAppSettings: union(reference(functionAppSettings.id),appSettings)
        functionAppName: functionAppName
    }
}

Thank you @alex-frankel

[alex-frankel]

Awesome! Out of curiosity did you try:

existingAppSettings: union(functionAppSettings.properties, appSettings)

functionAppSettings.properties should be the same as reference(functionAppSettings.id)

[SimonWahlin]

That works! Thank you!

I like bicep more an more for every day!
Now I just wish the ARM-api had a DevOps provider so we could manage our Azure DevOps org with bicep as well ;)

[alex-frankel]

maybe one day! glad everything is working well.

[gopinathch]

That works! Thank you!

I like bicep more an more for every day!
Now I just wish the ARM-api had a DevOps provider so we could manage our Azure DevOps org with bicep as well ;)

@SimonWahlin - will you be able to share scenarios or use cases on what you would like to achieve if that is available?

[SimonWahlin]

That works! Thank you!
I like bicep more an more for every day!
Now I just wish the ARM-api had a DevOps provider so we could manage our Azure DevOps org with bicep as well ;)

@SimonWahlin - will you be able to share scenarios or use cases on what you would like to achieve if that is available?

I'd be glad to, but maybe in a different forum?

[alex-frankel]

I think we can close this now that we have module + scope implemented. Thoughts @anthony-c-martin / @majastrz?

[SimonWahlin]

That works! Thank you!
I like bicep more an more for every day!
Now I just wish the ARM-api had a DevOps provider so we could manage our Azure DevOps org with bicep as well ;)

@SimonWahlin - will you be able to share scenarios or use cases on what you would like to achieve if that is available?

Since you are about to close this I'm taking the opportunity to highjack the Issue to reply to @gopinathch.

We want to create and configure Azure DevOps Projects using ARM-templates (pref bicep) so that we can deliver a new project to a team including example-git repo containing a markdown wiki with welcome information, example code and pipelines to get them started and links to our central repository with templates, pipelines and such.

The new project needs have pre-populated service connections to the teams dedicated landing zone subscriptions in Azure as well as service connections to services we use, for example SonarCloud.

The project need to be populated with a few custom roles that has custom permissions and maps to centrally managed Azure AD Groups (where we can make use of Access Review and other security features).

We want to keep all this configuration defined as code so we can prevent configuration drift and easily update projects base-configuration by changing the configuration and re-deploy, just like we do with infrastructure in Azure. This also opens the possibility for team members to request changes to their projects by a simple PR to the ARM template which would give us approval flow and traceability using the same tools and processes as we use for changing infrastructure.

Most of this is doable using the new Terraform provider for Azure DevOps, but since we use bicep/arm for everything else, I've become a bit spoiled of the automagic and amazing state-machine that is ARM. Keeping my own state in a file that has to be kept up to date with reality feels less tempting for each day that goes by.

Don't hesitate to reach out if you want more details, I think my email is public on my GitHub profile.

[alex-frankel]

Until we support templateSpec as a source for a module, we should treat this issue as HiPri as it is the only way to deploy a templateSpec

[alex-frankel]

We need to also check the behavior for the scope property, and ensure it allows for nested MG and tenant deployments.