{Doc} Fixed missing or incorrect code tags BULK (#16562)

2021-01-28 21:08:37 -07:00 · 2021-01-28 21:08:37 -07:00 · b5cc60ab5a
--- a/doc/authoring_help.md
+++ b/doc/authoring_help.md
@ -28,7 +28,7 @@ To override help for a given command:

 ### Example YAML help file, \_help.py

-```py
+```python
 #---------------------------------------------------------------------------------------------
 # Copyright (c) Microsoft Corporation. All rights reserved.
 # Licensed under the MIT License. See License.txt in the project root for license information.
@ -61,7 +61,7 @@ examples:

 You can also document groups using the same format.

-```py
+```python
 helps['account'] = """
 type: group
 short-summary: The account group
@ -87,7 +87,7 @@ examples:

 To verify the YAML help is correctly formatted, the command/group's help command must be executed at runtime.  For example, to verify "az account clear", run the command "az account clear -h" and verify the text.  

-Runtime is also when help authoring errors will be reported, such as documenting a parameter that doesn't exist.  Errors will only show when the CLI help is executed, so verifying the CLI help is required to ensure your authoring is correct.   
+Runtime is also when help authoring errors will be reported, such as documenting a parameter that doesn't exist.  Errors will only show when the Azure CLI help is executed, so verifying the Azure CLI help is required to ensure your authoring is correct.   

 # Other Help Authoring

@ -114,7 +114,7 @@ Page titles for your command groups as generated from the source are simply the

 ## Profile specific help

-The CLI supports multiple profiles. Help can be authored to take advantage of this.  
+The Azure CLI supports multiple profiles. Help can be authored to take advantage of this.  
 Commands available, arguments, descriptions and examples all change dynamically based on the profile in use.

 The `az cloud update --profile ...` command allows you to switch profiles.  
@ -135,7 +135,7 @@ The first example is only supported on the `latest` and `2018-03-01-hybrid` prof

 ### \_help.py

-```
+```console
    examples:
        - name: Create a storage account MyStorageAccount in resource group MyResourceGroup in the West US region with locally redundant storage.
          text: az storage account create -n MyStorageAccount -g MyResourceGroup -l westus --sku Standard_LRS
@ -147,10 +147,11 @@ The first example is only supported on the `latest` and `2018-03-01-hybrid` prof
          supported-profiles: 2017-03-09-profile
 ```

-Here is how this looks in CLI `--help`:
+Here is how this looks in Azure CLI `--help`:

 On profiles `latest` and `2018-03-01-hybrid`.
-```
+
+```console
 Examples
    Create a storage account MyStorageAccount in resource group MyResourceGroup in the West US
    region with locally redundant storage.
@ -159,7 +160,8 @@ Examples
 ```

 On profile `2017-03-09-profile`.
-```
+
+```console
 Examples
    Create a storage account MyStorageAccount in resource group MyResourceGroup in the West US
    region with locally redundant storage.
--- a/doc/authoring_tests.md
+++ b/doc/authoring_tests.md
@ -22,7 +22,7 @@ The rationale behind the nightly live test:
 2) The live scenario tests ensure the credibility of the tested scenario.
 3) The test recording tends to go stale. The sample it captures will eventually deviate from the actual traffic samples.
 4) The tests in playback mode does not verify the request body and it doesn't ensure the correct requests sequence.
-5) The unhealthy set of live tests prevent the CLI team from rebaselining tests rapidly.
+5) The unhealthy set of live tests prevent the Azure CLI team from rebaselining tests rapidly.
 6) Neglecting the live tests will reduce the quality and the credibility of the test bed.

 It is a requirement for the command owner to maintain their test in live mode.
@ -83,7 +83,7 @@ Here are some issues that may occur when authoring tests that you should be awar

 ### Sample 1. Basic fixture

-```Python
+```python
 from azure.cli.testsdk import ScenarioTest

 class StorageAccountTests(ScenarioTest):
@ -99,7 +99,7 @@ Notes:

 ### Sample 2. Validate the return value in JSON

-``` Python
+```python
 class StorageAccountTests(ScenarioTest):
    def test_list_storage_account(self):
        accounts_list = self.cmd('az storage account list').get_output_in_json()
@ -116,7 +116,7 @@ which may not stand in a live test environment.

 ### Sample 3. Validate the return JSON value using JMESPath

-``` Python
+```python
 from azure.cli.testsdk import ScenarioTest

 class StorageAccountTests(ScenarioTest):
@ -134,7 +134,7 @@ Notes:

 ### Sample 4. Prepare a resource group for a test

-``` Python
+```python
 from azure.cli.testsdk import ScenarioTest, ResourceGroupPreparer

 class StorageAccountTests(ScenarioTest):
@ -155,7 +155,7 @@ Notes:

 ### Sample 5. Get more from ResourceGroupPreparer

-``` Python
+```python
 class StorageAccountTests(ScenarioTest):
    @ResourceGroupPreparer(parameter_name='group_name', parameter_name_for_location='group_location')
    def test_create_storage_account(self, group_name, group_location):
@ -177,7 +177,7 @@ Notes:

 ### Sample 6. Random name and name mapping

-``` Python
+```python
 class StorageAccountTests(ScenarioTest):
    @ResourceGroupPreparer(parameter_name_for_location='location')
    def test_create_storage_account(self, resource_group, location):
@ -215,7 +215,7 @@ For example, note names like 'clitest.rg000001' in the sample recording below:
 they aren't the names of the resources which are actually created in Azure.
 They're replaced before the requests are recorded.

-``` Yaml
+```Yaml
 - request:
    body: '{"location": "westus", "tags": {"use": "az-test"}}'
    headers:
@ -254,7 +254,7 @@ to fully randomize the name.

 ### Sample 7. Prepare a storage account for tests

-``` Python
+```python
 from azure.cli.testsdk import ScenarioTest, ResourceGroupPreparer, StorageAccountPreparer

 class StorageAccountTests(ScenarioTest):
@ -273,13 +273,13 @@ Note:
 3. The preparers communicate among themselves by adding values to the `kwargs` of the decorated methods. Therefore the `StorageAccountPreparer` uses the resource group created in the preceding `ResourceGroupPreparer`.
 4. The `StorageAccountPreparer` can be further customized to modify the parameters of the created storage account:

-``` Python
+```python
@StorageAccountPreparer(sku='Standard_LRS', location='southcentralus', parameter_name='storage')
 ```

 ### Sample 8. Prepare multiple storage accounts for tests

-``` Python
+```python
 class StorageAccountTests(ScenarioTest):
    @ResourceGroupPreparer()
    @StorageAccountPreparer(parameter_name='account_1')
@ -304,7 +304,7 @@ to make diffs and updates clearer.

 ### Sample 9. Assert Specific Error Occurs

-``` Python
+```python
 with self.assertRaisesRegexp(CLIError, "usage error: --vnet NAME --subnet NAME | --vnet ID --subnet NAME | --subnet ID"):
            self.cmd('container create -g {rg} -n {container_group_name} --image nginx --vnet {vnet_name}')
 ```
--- a/doc/classic_cli_migration.md
+++ b/doc/classic_cli_migration.md
@ -85,13 +85,14 @@ While most commands keep the same group and command names between the Azure clas
 Mutate operations now use the `update` verb instead of `set`.  While the classic CLI
 exposed some common operations as parameters, such as:

-```
+```azurecli
 $ azure vm set -g MyGroup -n MyName --nic-ids $MyNicID
 $ azure vm set -g MyGroup -n MyName --tags myTagName=MyTagValue
 ```

 The Azure CLI `update` commands work generically against the resource, for example:
-```
+
+```azurecli
 $ az vm update -g MyGroup -n MyName --add networkProfile.networkInterfaces primary=false id=$MyNicID
 $ az vm update -g MyGroup -n MyName --set tags.myTagName=MyTagValue
 ```
@ -115,7 +116,7 @@ parameter flags: `az vm show -g MyRG -n MyName`.
 In addition, when an input value is missing, we will show an error indicating the
 missing parameters, instead of prompting the user automatically:

-```
+```azurecli
 $ az vm show
 az vm show: error: (--name --resource-group | --ids) are required
 ```
@ -123,7 +124,7 @@ az vm show: error: (--name --resource-group | --ids) are required
 In addition to using resource groups and names (`-g`, `-n`), you can also refer to
 resources directly by ID value using `--ids`:

-```
+```bash
 $ MyVar=$(az vm list --query [0].id --out tsv)
 $ echo $MyVar
 /subscriptions/xxxx/resourceGroups/VMGROUP1/providers/Microsoft.Compute/virtualMachines/VM-Data
@ -135,7 +136,7 @@ VMGROUP1         VM-Data  63edd6a0-2796-49e6-acc1-ad3f8bd94f13  westus      Succ

 When working with files, you can use the `@` symbol to indicate the contents of a file or file descriptor.

-```
+```azurecli
 $ az role create --role-definition @MyOnCallRoleDef.json
 ```

@ -159,7 +160,7 @@ Tips:
 * Avoid using `--out jsonc` output programmatically as not all tools will accept the ANSI values that provide color in the Shell
 * Currently, `--out table` does not work with some formatted outputs.

-```
+```azurecli
 $ az vm list --query [0].name --out json
 "VM-Data"
 $ az vm list --query [0].name --out tsv
@ -175,7 +176,7 @@ VM-Data
 A common pattern in Azure classic CLI scripts is using command-line tools, such as
 AWK, grep, and jq, to extract values from output documents:

-```
+```azurecli
 $ azure vm list --json \
     | jq -r '.[].storageProfile.osDisk.vhd.uri' \
     | cut -d / -f3 \
@ -189,7 +190,7 @@ $ MY_SUBSCRIPTION_ID=$(azure account show --json | jq -r '.[0].id')
 With the Azure CLI, you can now use the `--query '[expression]'` parameter and the [JMESPath](http://jmespath.org/)
 query language to extract values.

-```
+```azurecli
 $ az vm list --query "[].{name:name,os:storageProfile.osDisk.osType}" --out table
 Name           Os
 -------------  -------
@ -227,7 +228,7 @@ $ az vm list --query "[].{name:name,os:storageProfile.osDisk.osType}" --out json

 You can also extract single values.  Using `--out tsv` will prevent any unintended quotes:

-```
+```azurecli
 az vm list --query "[0].id" --out tsv
 /subscriptions/xxxx/resourceGroups/VMGROUP1/providers/Microsoft.Compute/virtualMachines/VM-Web
 ```
--- a/doc/extensions/authoring.md
+++ b/doc/extensions/authoring.md
@ -11,18 +11,18 @@ This represents the most common sequence of steps you would perform to create, t
 Development of extensions have been simplified by the public release of the azdev CLI. Please visit https://github.com/Azure/azure-cli-dev-tools for more information.

 1. In a new virtual environment, install azdev: `pip install azdev`
-2. Setup your CLI and install your extension:
+2. Setup your Azure CLI and install your extension:
  - If you prefer to be guided via an interactive experience, just run `azdev setup` with no additional arguments.
  - If you are creating a brand new extension, run `azdev setup -r <PATH>` to add the repo to your extension dev sources. From there you can run `azdev extension create` to generate and install starter code.
  - If you are only developing on an existing extension, run: `azdev setup -r <PATH> -e <NAME>` where PATH is the path to the local git folder your extension resides in and NAME is the name of your extension. If you don't know the name of the extension, you can omit `-e` to complete the setup. Then you can run `azdev extension list -o table` to see which extensions are installable for your repo and add that extension with `azdev extension add <NAME>`.
-  - If you would like to develop for a CLI module and your extension, run the above, but include `-c [<CLI_PATH>]` where CLI_PATH is the path to your local Azure CLI repo. If omitted, the command will attempt to find the repo by crawling your current working directory.
+  - If you would like to develop for an Azure CLI module and your extension, run the above, but include `-c [<CLI_PATH>]` where CLI_PATH is the path to your local Azure CLI repo. If omitted, the command will attempt to find the repo by crawling your current working directory.

 ### Create

 Run `azdev extension create <NAME>` to create skeleton code for a new extension. As an example (for a fictional widget API):

-```
-azdev extension create  widget --local-sdk <PATH TO SDK ZIP> --operation-name WidgetOperations --client-name WidgetManagementClient --sdk-property widget_name --github-alias myalias
+```azurecli
+azdev extension create widget --local-sdk <PATH TO SDK ZIP> --operation-name WidgetOperations --client-name WidgetManagementClient --sdk-property widget_name --github-alias myalias
 ```

 The fields `--operation-name`, `--client-name` and `--sdk-property` will come from a review of your Python SDK.
@ -37,7 +37,7 @@ Periodically run the following to ensure your extension will pass CI:
 `azdev test <NAME>`
 `azdev linter <NAME>`

-Address comments as appropriate and consult the CLI team if something is unclear.
+Address comments as appropriate and consult the Azure CLI team if something is unclear.

 ### Publish

@ -80,7 +80,8 @@ Normally, you will have you extension installed in dev mode and your code change
 `azdev extension remove myexampleextension`

 Verify it is removed:
-```
+
+```azurecli
 az extension list -ojson
 []
 ```
@ -91,7 +92,7 @@ az extension list -ojson

 You can verify the extension was installed as follows:

-```
+```azurecli
 az extension list -ojson
 [
  {
@ -120,7 +121,7 @@ See [Extension Metadata](metadata.md) for more information.
 ### Limit dependencies in setup.py

 - Before adding a dependency to your setup.py, check that it's not already available in [azure-cli-core setup.py](https://github.com/Azure/azure-cli/blob/master/src/azure-cli-core/setup.py).
- Azure SDK or Azure Management SDK dependencies may be overridden by the versions installed as requirements of azure-cli-core. If you use any, test carefully, gracefully handle API changes, and be prepared to release updates. You might also consider rebasing the libraries under a different namespace (besides `azure`) to avoid conflicting with core CLI functionality. You can use [autorest](https://github.com/azure/autorest) to generate your SDK into a package that isn't under the `azure` directory.
+- Azure SDK or Azure Management SDK dependencies may be overridden by the versions installed as requirements of azure-cli-core. If you use any, test carefully, gracefully handle API changes, and be prepared to release updates. You might also consider rebasing the libraries under a different namespace (besides `azure`) to avoid conflicting with core Azure CLI functionality. You can use [autorest](https://github.com/azure/autorest) to generate your SDK into a package that isn't under the `azure` directory.

 ### How do I know I'm using my dev extension(s)?

@ -128,7 +129,7 @@ See [Extension Metadata](metadata.md) for more information.

 ### Test your extension on Python 3

- The CLI supports Python 3.6, 3.7, 3.8 so verify that your extension does the same.
+- The Azure CLI supports Python 3.6, 3.7, 3.8 so verify that your extension does the same.
 - You can create virtual environments for different versions and run your extension in them.
 - e.g. `python3.6 -m venv env36` and `python3.8 -m venv env38`.

--- a/doc/local_context_guidelines.md
+++ b/doc/local_context_guidelines.md
@ -39,6 +39,7 @@ We define local context attribute for some command parameters by default. Comman
 All these parameters are listed here:

 - *resource_group_name*
+
 ```python
    local_context_attribute=LocalContextAttribute(
        name='resource_group_name',
@ -48,22 +49,26 @@ All these parameters are listed here:
 ```

 - *vnet_name*
+
 ```python
    local_context_attribute=LocalContextAttribute(name='vnet_name', actions=[LocalContextAction.GET])
 ```

 - *subnet*
+
 ```python
    local_context_attribute=LocalContextAttribute(name='subnet_name', actions=[LocalContextAction.GET])
 ```

 For example, below is function signature for `az network vnet create`:
+
 ```python
 def create_vnet(cmd, resource_group_name, vnet_name, vnet_prefixes='10.0.0.0/16',
                subnet_name=None, subnet_prefix=None, dns_servers=None,
                location=None, tags=None, vm_protection=None, ddos_protection=None,
                ddos_protection_plan=None):
 ```
+
 As `resource_group_name` is defined in the signature, it will automatically support local context.


@ -75,15 +80,18 @@ As `resource_group_name` is defined in the signature, it will automatically supp

 ## Examples
 In order to create a webapp, a user needs to prepare an appservice plan first. Previously the user needed to run below commands to complete this scenario:
-```bash
+
+```azurecli
 az group create --name myResourceGroup --location westus
 az appservice plan create -g myResourceGroup --name myPlan
 az webapp create -g myResourceGroup --plan myPlan --name myWebapp
 ```
+
 The user has to input resource group name 3 times and plan name 2 times for this scenario. To reduce these duplicate type in, we need to enable local context feature for these parameters as below:

 - `az group create`: *set resource group name*
 > azure-cli/azure/cli/command_modules/resource/_params.py
+
 ```python
 # define SET action for resource group name
 with self.argument_context('group create') as c:
@ -94,6 +102,7 @@ with self.argument_context('group create') as c:
 - `az appservice plan create`: *get resource group name & set plan name*

 > azure-cli/azure/cli/command_modules/appservice/custom.py
+
 ```python
 # get resource group name from local context by define function argument name as `resource_group_name`
 def create_app_service_plan(cmd, resource_group_name, name, is_linux, hyper_v, per_site_scaling=False,
@ -102,6 +111,7 @@ def create_app_service_plan(cmd, resource_group_name, name, is_linux, hyper_v, p
 ```

 > azure-cli/azure/cli/command_modules/appservice/_params.py
+
 ```python
 # define SET action for plan name
 with self.argument_context('appservice plan create') as c:
@ -112,6 +122,7 @@ with self.argument_context('appservice plan create') as c:
 - `az webapp create`: *get resource group name & get plan name & set webapp name*

 > azure-cli/azure/cli/command_modules/appservice/custom.py
+
 ```python
 # get resource group name from local context by define function argument name as `resource_group_name`
 def create_webapp(cmd, resource_group_name, name, plan, runtime=None, startup_file=None,  # pylint: disable=too-many-statements,too-many-branches
@ -122,6 +133,7 @@ def create_webapp(cmd, resource_group_name, name, plan, runtime=None, startup_fi
 ```

 > azure-cli/azure/cli/command_modules/appservice/_params.py
+
 ```python
 # define SET action for webapp name
 # define GET action for plan name
--- a/doc/parampersist_localcontext_guidelines.md
+++ b/doc/parampersist_localcontext_guidelines.md
@ -39,6 +39,7 @@ We define local context attribute for some command parameters by default. Comman
 All these parameters are listed here:

 - *resource_group_name*
+
 ```python
    local_context_attribute=LocalContextAttribute(
        name='resource_group_name',
@ -48,22 +49,26 @@ All these parameters are listed here:
 ```

 - *vnet_name*
+
 ```python
    local_context_attribute=LocalContextAttribute(name='vnet_name', actions=[LocalContextAction.GET])
 ```

 - *subnet*
+
 ```python
    local_context_attribute=LocalContextAttribute(name='subnet_name', actions=[LocalContextAction.GET])
 ```

 For example, below is function signature for `az network vnet create`:
+
 ```python
 def create_vnet(cmd, resource_group_name, vnet_name, vnet_prefixes='10.0.0.0/16',
                subnet_name=None, subnet_prefix=None, dns_servers=None,
                location=None, tags=None, vm_protection=None, ddos_protection=None,
                ddos_protection_plan=None):
 ```
+
 As `resource_group_name` is defined in the signature, it will automatically support local context.


@ -74,16 +79,20 @@ As `resource_group_name` is defined in the signature, it will automatically supp
 - Define `SET` action only in `create` command.

 ## Examples
+
 In order to create a webapp, a user needs to prepare an appservice plan first. Previously the user needed to run below commands to complete this scenario:
-```bash
+
+```azurecli
 az group create --name myResourceGroup --location westus
 az appservice plan create -g myResourceGroup --name myPlan
 az webapp create -g myResourceGroup --plan myPlan --name myWebapp
 ```
+
 The user has to input resource group name 3 times and plan name 2 times for this scenario. To reduce these duplicate type in, we need to enable local context feature for these parameters as below:

 - `az group create`: *set resource group name*
 > azure-cli/azure/cli/command_modules/resource/_params.py
+
 ```python
 # define SET action for resource group name
 with self.argument_context('group create') as c:
@ -94,6 +103,7 @@ with self.argument_context('group create') as c:
 - `az appservice plan create`: *get resource group name & set plan name*

 > azure-cli/azure/cli/command_modules/appservice/custom.py
+
 ```python
 # get resource group name from local context by define function argument name as `resource_group_name`
 def create_app_service_plan(cmd, resource_group_name, name, is_linux, hyper_v, per_site_scaling=False,
@ -102,6 +112,7 @@ def create_app_service_plan(cmd, resource_group_name, name, is_linux, hyper_v, p
 ```

 > azure-cli/azure/cli/command_modules/appservice/_params.py
+
 ```python
 # define SET action for plan name
 with self.argument_context('appservice plan create') as c:
@ -112,6 +123,7 @@ with self.argument_context('appservice plan create') as c:
 - `az webapp create`: *get resource group name & get plan name & set webapp name*

 > azure-cli/azure/cli/command_modules/appservice/custom.py
+
 ```python
 # get resource group name from local context by define function argument name as `resource_group_name`
 def create_webapp(cmd, resource_group_name, name, plan, runtime=None, startup_file=None,  # pylint: disable=too-many-statements,too-many-branches
@ -122,6 +134,7 @@ def create_webapp(cmd, resource_group_name, name, plan, runtime=None, startup_fi
 ```

 > azure-cli/azure/cli/command_modules/appservice/_params.py
+
 ```python
 # define SET action for webapp name
 # define GET action for plan name
--- a/doc/use_cli_in_airgapped_clouds.md
+++ b/doc/use_cli_in_airgapped_clouds.md
@ -26,7 +26,8 @@ MSI | https://azurecliprod.blob.core.windows.net/msi/azure-cli-<version\>.msi |
 2. The CLI RPM package depends on a `python3` package and you'll need to install it separately while DEB and MSI packages already have a bundled Python in them.

 If you need to install and use Azure CLI in your pipeline, you could upload the Azure CLI package in a storage account that is accessible in the airgapped cloud, then you can download the package from the storage account and install it in your pipeline scripts. For instance, an Azure CLI deb package can be downloaded and installed with the following command:
-```
+
+```bash
 curl -Ls -o azure-cli.deb https://mysa.airgapped.cloud.net/packages/azure-cli.deb && dpkg -i azure-cli.deb
 ```

@ -73,7 +74,8 @@ Please follow the first solution in [Work behind a proxy](https://docs.microsoft

 ## Login with service principal
 Use the service principal that was granted permission to access a subscription in the airgapped cloud to login.
-```
+
+```azurecli
 az login --service-principal -u <service principal id> -p <service principal password> --tenant <tenant id>
 ```

--- a/doc/use_cli_with_git_bash.md
+++ b/doc/use_cli_with_git_bash.md
@ -10,13 +10,16 @@ We do not recommend to use `az` installed through `pip install azure-cli` on Git
 ### Auto-translation of Resource IDs

 On Git Bash, if you specify command-line options starting with a slash, POSIX-to-Windows path conversion will kick in. This causes an issue for passing ARM Resource IDs, like:
-```
+
+```azurecli
 $ az vm show --ids "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm"

 invalid resource ID: C:/Program Files/Git/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm
 ```
+
 To disable the path conversion. You can set environment variable `MSYS_NO_PATHCONV=1` or set it temporarily when a running command:
-```
+
+```azurecli
 $ MSYS_NO_PATHCONV=1 az vm show --ids "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm"
 ```

@ -26,15 +29,18 @@ More discussions [here](https://stackoverflow.com/questions/7250130/how-to-stop-

 #### Quoting Issues
 The double quotes will be stripped in the value and cause trouble when there are spaces inside the quotes since Git Bash will treat each parts separated by spaces as an individual command option.
-```
+
+```azurecli
 $ az find "vm create"
 $ Command arguments: ['find', 'vm', 'create', '--debug']
 ...
 az: error: unrecognized arguments: create
 ...
 ```
+
 You can wrap the value with additional single quotes to avoid the issue:
-```
+
+```azurecli
 $ az find '"vm create"' --debug
 $ Command arguments: ['find', 'vm create', '--debug']
 ...