Azure
Paste parsing of ARM template with languageVersion 2.0 fails in VS Code Bicep extension
Bicep version
Bicep extension version: v0.28.1
Azure CLI bicep version: Bicep CLI version 0.28.1 (ba1e9f8c1e)
Describe the bug
Earlier we could just copy the ARM template from a deployment in Azure Portal and paste that in a bicep file and we got a
bicep script based on the ARM template to work with. But now it seems that Azure Portal has switched to a new format with languageVersion set to 2.0 and these templates fails with the error Could not convert pasted text into Bicep: [13:16]: Decompilation of symbolic name templates is not currently supported.
To Reproduce Steps to reproduce the behavior:
- Go to a resource group in Azure Portal and Deployments
- Take one of the deployments and go to the Template section
- Copy the template content
- Create a bicep file in Visual Studio Code
- Paste the template content
The error occurs as described above.
Additional context
Investigation has revealed that it is because the languageVersion 2.0 uses a new format on the resources field that isn't supported as the message states, but the problem is that this is now the default format for template provided by Azure Portal, so the bicep module should support it.
Are these templates you are downloading from end user created templates? Or are these templates that were executed as a result of creating a resource in the portal?
If it's the former, then the original bicep should be available to you as most likely a colleague created that bicep file and deployed it.
@alex-frankel Well, that's not the point where they come from (but the current example I had here was created using a bicep but the bicep went lost due to SSD crash, but this applies to other deployment options as well). the point is that the copy/paste functionality doesn't support ARM templates of where the language version is 2.0 and new format at least around the resources section (but may be more).. Since Azure Portal delivers some of the templates for deployed resources as this new ARM template format the ARM -> Bicep parser should support this.
Understood, but I wanted to make sure I clarified how this was presenting itself so we can prioritize accordingly. I agree the decompiler should support this.