Az PowerShell Bicep support feedback
Closed this issue · 8 comments
I looked at the code implemented so far to support the deployment of .bicep files using the New-Az*Deployment cmdlets and have some feedback.
Looking at src/Resources/ResourceManager/Utilities/BicepUtility.cs I see some potential issues.
There is no check to verify which version of Bicep CLI is running on the device. There should be a check that verifies the version installed and specify a minimum required version of Bicep CLI. If the version is not up to date, the user should get a Warning and be prompted to update the CLI. If older versions of bicep is installed there is a risk that build will run successfully but the deployment using the compiled .json will fail. This is extra important if the bicep support should be aligned with the release of Bicep v0.3.
The error message if bicep is not installed in src/Resources/ResourceManager/Properties/Resources.resx should link to https://github.com/Azure/bicep/blob/main/docs/installing.md#install-the-bicep-cli instead of releases in the git repo. It is not clear how to install bicep using the assets in the release. Only the Windows Installer will actually install the CLI and add Bicep to the users path. Or even better create cmdlets to Install/Update/Remove bicep CLI using the Az Module. If Bicep CLI is a requirement for the deployment of .bicep files with the Az module the module should provide tools to install the dependencies.
<data name="BicepNotFound" xml:space="preserve">
<value>Cannot find Bicep. Please add Bicep to your PATH or visit https://github.com/Azure/bicep/releases to install Bicep.</value>
</data>
@StefanIvemo , Thanks for suggestion. We will change the link in this upcoming release.
Creating cmdlets to support Install/Update/Remove tool from customer environment is out of the scope of Azure PowerShell. I prefer to asking PowerShell to support that in a generic way.
Regarding to the version of Bicep, we are hesitating to support it because Becip is still under preview and Azure PowerShell shouldn't install it on behave of customer. And we didn't figure out the way to check which version is expected. Feel free to share your insight.
I have changed my mind on the version check. It should be up to the user to decide which version of Bicep to use. If I have authored all my bicep templates using a specific release for example v0.2.212, then I should be able to use that version to deploy my .bicep files. A newer release might implement breaking changes that causes my template to brake if I'm forced to use a newer version. New-Az*Deployment can just verify that I have Bicep installed and then try to deploy my template.
I do believe that it could be a good idea though to inform the user which Bicep version is used during deployment, at least if I'm using the -Verbose switch. And also any build warnings generated from bicep build should be outputted as well.
Running New-AzResourceGroupDeployment -ResourceGroupName nsgs-rg -TemplateFile .\nsg-1.bicep -TemplateParameterFile .\nsg-1.parameters.json -Verbose , should generate an output like:
VERBOSE: Using Bicep release v0.2.328
VERBOSE: Warning BCP081: Resource type "Microsoft.Network/networkSecurityGroups@2020-08-01" does not have types available.
VERBOSE: Performing the operation "Creating Deployment" on target "nsgs-rg".
VERBOSE: 21:06:47 - Template is valid.
VERBOSE: 21:06:48 - Create template deployment 'nsg-1'
VERBOSE: 21:06:48 - Checking deployment status in 5 seconds
VERBOSE: 21:06:53 - Resource Microsoft.Network/networkSecurityGroups 'steffes-super-cool-nsg' provisioning status is succeeded
Any thoughts on this @alex-frankel?
@StefanIvemo / @alex-frankel I think it is possible to redirect the output of bicep to the verbose / debug stream of the PowerShell cmdlet. Would this be acceptable?
Let us know If you have other ideas.
I think that is a good idea. Could we also add the bicep version that is being used? That is not something we output with the bicep CLI today.
I'd be happy if we could get something similar to my example above. Output Bicep version and any build warnings. I believe that information can be useful in a couple of scenarios.
@StefanIvemo - bicep CLI will emit any errors or warnings, so I think we only need to add the version to the output to match what you have above. WDYT?
@alex-frankel Ok! Version should be enough then.
The link has been changed to https://github.com/Azure/bicep/blob/main/docs/installing.md in this upcoming release.
We plan to redirect the output of bicep to the verbose/debug stream and add bicep version to output in the next release.