Spike: Review updating bicep examples to reflect using bicep to retrieve output variables of previous deployment

[shawngib]

Is your feature request related to a problem? Please describe.
To work with existing MLZ deployment in an effort to add additional capabilities or workloads it important to know a number of outputs of existing deployment to place as parameters into new deployment. Our current example for new work load uses a cli command to pull the json:

az deployment sub show \
  --subscription $deploymentSubscription \
  --name "myMlzDeployment" \
  --query properties.outputs

The goal is to create workload deployment bicep code that doesn;t require manually adding this output as input to the new deployment. Currently looks like this:

workloadSubscriptionId="12345678-1234..."
location="eastus"
workloadName="myNewWorkload"

az deployment sub create \
  --subscription $workloadSubscriptionId \
  --location $location \
  --name $workloadName \
  --template-file "./newWorkload.bicep" \
  --parameters \
  workloadName="$workloadName" \
  hubSubscriptionId="$hubSubscriptionId" \
<additonal parameters removed to brevity>

Describe the solution you'd like
For the solution it is recommended to use a bicep resource by calling Microsoft.Resources/deployments@2021-04-01 existing and then referencing its output in the new module or main file.

Example:

targetScope = 'subscription'

param name string

resource deployments 'Microsoft.Resources/deployments@2021-04-01' existing = {
  name: name
}

output deploymentsObj object = deployments

Describe alternatives you've considered
Alternatives are to use scripting and local files.

[shawngib]

Final test prove this to be not sufficient. The primary problem is in the early stages of the ARM pipeline. While some output maybe available the result of arrays are unknown so the bicep/arm code doesn't understand looping and indexes in the array so referring to them in the subsequent deployment will fail for 'not knowing' .

This should be tracked since this should work in the future but for purposes needed today it is not a working solution.

There still maybe an opportunity to stay all Bicep by using the above to create the output file and simply referring to it in the new deployment file. For example:

az deployment sub create -f ./Mission.Workload/variables.bicep -n shawngibbs18 -l usgovvirginia  > output.json