Add "Insert Resource" to the Bicep.exe file, not just VS code extension

[ChristopherGLewis]

Is your feature request related to a problem? Please describe.
The "Insert Resource" command is excellent but only works in VS code as a function of the VS Code extension. Please add this to the bicep executable as

bicep.exe import "/subscription/.../object/ID"

Describe the solution you'd like
By adding this feature to the Bicep.exe file, scripting the output of many objects can be simplified.

bicep import "id1" >> outfile.bicep
bicep import "id2" >> outfile.bicep
bicep import "id3" >> outfile.bicep
bicep import "id4" >> outfile.bicep

IMPORT might be the wrong action word for the EXE. We have build and Decompile, maybe something more like GET or READ.

[StefanIvemo]

My suggestion is to name this command bicep export.

bicep export "/subscription/.../object/ID" --outfile "c:\temp\myResource.bicep"

[BenjaminEngeset]

Any news regarding this?

[anthony-c-martin]

Interesting suggestion! Would there be any objection to building this into AzCLI & AzPwsh instead of the Bicep CLI?

e.g. something like:

az bicep insert-resource --ids '<id>' --out-file 'res.bicep'

Conceptually this is also quite similar to the export + decompile sinppet here - apart from simplicity, are there any benefits to having "Insert Resource" in the CLI instead of using this snippet?

[BenjaminEngeset]

@anthony-c-martin

Not any objection, as long the binary does the job, altrough I would be a big fan of seeing this in the Bicep CLI binary.

Reason for not using the already existing export + decompile is that quite frankly often you don't have the JSON or you don't want to download the JSON and manually decompile it.

Most people are just interacting with the resources directly by clickops or devops.

Having this bicep export functionality in place will leverage a "new world" where you can just call to Azure, traverse thru everything and download the complete environment in bicep in source control.

It will enable teams that do not have their Azure stack in neither bicep or IaC at all to get it and will be a MAJOR improvement. Same goes for resource declaration that happends manually by clickops.

[ChristopherGLewis]

Interesting suggestion! Would there be any objection to building this into AzCLI & AzPwsh instead of the Bicep CLI?

e.g. something like:

az bicep insert-resource --ids '<id>' --out-file 'res.bicep'

Conceptually this is also quite similar to the export + decompile sinppet here - apart from simplicity, are there any benefits to having "Insert Resource" in the CLI instead of using this snippet?

The two commands are not functionally the same. The VSCode bicep insert resource is scoped to a single resource, whereas az group export has to act on a group. There is no az resource export command.

For example, pointing bicep insert resource at a Resource Group produces:

@description('Generated from /subscriptions/xxxx-xxxx-xxxx/resourceGroups/myRG')
resource myRG 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'myRG'
  location: 'eastus'
  tags: {}
  properties: {}
}

Note this is a bicep file for the Resource Group, not any objects in it.

The Az command your proposing does this:

az group export --resource-group 'MyRG

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccounts_mystorageacct_name": {
      "type": "String"
    }
  },
  "resources": [
    {
      "apiVersion": "2021-09-01",
      "kind": "StorageV2",
      "location": "eastus",
      "name": "[parameters('storageAccounts_mystorageacct_name')]",
      "properties": {
        "accessTier": "Cool",
        "allowBlobPublicAccess": true,
        "allowCrossTenantReplication": true,
        "allowSharedKeyAccess": true,
        "defaultToOAuthAuthentication": false,
        "minimumTlsVersion": "TLS1_2",
        "publicNetworkAccess": "Enabled",
        "supportsHttpsTrafficOnly": true
      },
      "sku": {
        "name": "Standard_LRS",
        "tier": "Standard"
      },
      "type": "Microsoft.Storage/storageAccounts"
    }
  ],
  "variables": {}
}

Which is a complete ARM template for the objects inside the RG, not the RG itself.

[anthony-c-martin]

Thanks @ChristopherGLewis, that's one of the things I was hoping to get at with my questioning. You're right - ARM's export is more limited in that it can only be used to fetch resources inside a resource group, and has no support for subscription, tenant, extension resources etc.

I do still feel like conceptually this would fit better as an az command, but agree that providing a one-liner equivalent of the 'export-and-decompile' isn't going to provide the same set of functionality as is desired here.

[pinakighatak]

Interesting suggestion! Would there be any objection to building this into AzCLI & AzPwsh instead of the Bicep CLI?
e.g. something like:

az bicep insert-resource --ids '<id>' --out-file 'res.bicep'

Conceptually this is also quite similar to the export + decompile sinppet here - apart from simplicity, are there any benefits to having "Insert Resource" in the CLI instead of using this snippet?

The two commands are not functionally the same. The VSCode bicep insert resource is scoped to a single resource, whereas az group export has to act on a group. There is no az resource export command.

For example, pointing bicep insert resource at a Resource Group produces:

@description('Generated from /subscriptions/xxxx-xxxx-xxxx/resourceGroups/myRG')
resource myRG 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'myRG'
  location: 'eastus'
  tags: {}
  properties: {}
}

Note this is a bicep file for the Resource Group, not any objects in it.

The Az command your proposing does this:

az group export --resource-group 'MyRG

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccounts_mystorageacct_name": {
      "type": "String"
    }
  },
  "resources": [
    {
      "apiVersion": "2021-09-01",
      "kind": "StorageV2",
      "location": "eastus",
      "name": "[parameters('storageAccounts_mystorageacct_name')]",
      "properties": {
        "accessTier": "Cool",
        "allowBlobPublicAccess": true,
        "allowCrossTenantReplication": true,
        "allowSharedKeyAccess": true,
        "defaultToOAuthAuthentication": false,
        "minimumTlsVersion": "TLS1_2",
        "publicNetworkAccess": "Enabled",
        "supportsHttpsTrafficOnly": true
      },
      "sku": {
        "name": "Standard_LRS",
        "tier": "Standard"
      },
      "type": "Microsoft.Storage/storageAccounts"
    }
  ],
  "variables": {}
}

Which is a complete ARM template for the objects inside the RG, not the RG itself.

Please know, it is actually possible to extract a single resource from a given resource group like this:

#export the resource to a ARM template
az group export -g MyResourceGroupName --resource-ids "resourceId" >myresource.json