Azure
[ARM] `az bicep`: Add configs to allow disabling version checks and using Bicep CLI from PATH
Related command
az bicep *
Description
The az bicep commands download Bicep CLI automatically if it does not exist on $AZURE_CONFIG_DIR/bin. This is causing an GitHub API throttling issue if users uses the Azure CLI ADO task, as each task run creates an empty azure config directory. The PR adds two configurations bicep.use_binary_from_path and bicep.check_version to allow users to reuse the pre-installed Bicep CLI on the CLI runners and to disable version checks for each az bicep command run.
Closes https://github.com/Azure/bicep/issues/9452.
Testing Guide
Set bicep.use_binary_from_path and bicep.check_version and run any az bicep commands.
History Notes
[ARM] az bicep: Add configuration bicep.use_binary_from_path. Possible values include if_running_in_ci (default) and Booleans
[ARM] az bicep: Add configuration bicep.check_version that accepts Boolean values. If set to False, version checks for Bicep CLI will be disabled
This checklist is used to make sure that common guidelines for a pull request are followed.
-
[ ] The PR title and description has followed the guideline in Submitting Pull Requests.
-
[ ] I adhere to the Command Guidelines.
-
[ ] I adhere to the Error Handling Guidelines.
The PR adds two configurations bicep.use_binary_from_path and bicep.check_version to allow users to reuse the pre-installed Bicep CLI on the CLI runners and to disable version checks for each az bicep command run.
May I ask how users know about these two new configurations. Is there any related documentation? Or could we consider including their introduction in the help message?
The PR adds two configurations bicep.use_binary_from_path and bicep.check_version to allow users to reuse the pre-installed Bicep CLI on the CLI runners and to disable version checks for each az bicep command run.
May I ask how users know about these two new configurations. Is there any related documentation? Or could we consider including their introduction in the help message?
Ah, I was going to ask the same question. Is adding docs for custom configurations to the help message the preferred way? Do we have an official guideline?
[ARM] BREAKING CHANGE (for GitHub Actions and Azure Pipeline users): az bicep: Add configuration bicep.use_binary_from_path. Possible values include if_running_in_ci (default) and Booleans. Setting the config True forces the az bicep commands to use the Bicep executable added to PATH, which indicates that the user is intended to manage the Bicep CLI, and version checks will be disabled. With if_running_in_ci, GitHub Actions and Azure Pipeline users may expect some delay (usually a few days) in getting the latest version of Bicep CLI, since the az bicep commands will use the pre-installed Bicep CLI on the build agents, but the build agents has a different release cycle. The benefit is that the az bicep commands will not download the Bicep CLI on each pipeline run. To keep the old behavior, users may set the value to False.
Since this is not a breaking change release window for CLI (the breaking change window only twice a year: Build sprint and Ignite sprint), do we have any way to avoid this breaking change?
[ARM] BREAKING CHANGE (for GitHub Actions and Azure Pipeline users): az bicep: Add configuration bicep.use_binary_from_path. Possible values include if_running_in_ci (default) and Booleans. Setting the config True forces the az bicep commands to use the Bicep executable added to PATH, which indicates that the user is intended to manage the Bicep CLI, and version checks will be disabled. With if_running_in_ci, GitHub Actions and Azure Pipeline users may expect some delay (usually a few days) in getting the latest version of Bicep CLI, since the az bicep commands will use the pre-installed Bicep CLI on the build agents, but the build agents has a different release cycle. The benefit is that the az bicep commands will not download the Bicep CLI on each pipeline run. To keep the old behavior, users may set the value to False.
Since this is not a breaking change release window for CLI (the breaking change window only twice a year: Build sprint and Ignite sprint), do we have any way to avoid this breaking change?
I just removed BREAKING CHANGE from the note. Technically, it's not a breaking change on the Azure CLI side.
Ah, I was going to ask the same question. Is adding docs for custom configurations to the help message the preferred way? Do we have an official guideline?
Our suggestion is usually to describe the configurations to be used in the help message, or write a concept document for these configurations and then reference the doc link in the help message
[ARM] az bicep: Add configuration bicep.use_binary_from_path. Possible values include if_running_in_ci (default) and Booleans. Setting the config True forces the az bicep commands to use the Bicep executable added to PATH, which indicates that the user is intended to manage the Bicep CLI, and version checks will be disabled. With if_running_in_ci, GitHub Actions and Azure Pipeline users may expect some delay (usually a few days) in getting the latest version of Bicep CLI, since the az bicep commands will use the pre-installed Bicep CLI on the build agents, but the build agents has a different release cycle. The benefit is that the az bicep commands will not download the Bicep CLI on each pipeline run. To keep the old behavior, users may set the value to False
This description of history note is too long. It is suggested to simplify it and then write more details into the code comments