Open heaths opened 1 week ago
Alternatively, maybe instead of a resourceType
we just have a filter
. Then template authors can use whatever filter they want, such as resourceType eq 'Microsoft.KeyVault/vaults' and location eq $location
. Though, to really make that work we'd need to support variable replacement, which also means resolving parameters sequentially, ideally doing location before all others because it'd be a likely filter.
I decided to make resourceType
required for use in templates. As I was thinking through the scenarios and considering how to approach documentation, I realized that any resource is useless in a template (but allow the underlying prompting functions to do it in case that's useful down the road). You can't declare an existing
resources in Bicep without knowing the type. You can't use ARM or Bicep template functions reference()
or resourceId()
without knowing the type. You also can't conceptually reference just any resource type e.g., you need to calculate a connection string to AppInsights but someone selected a Key Vault resource. It just doesn't make sense not to require resourceType
in this case.
That would be one problem with a general filter
as I proposed above as well. So maybe we keep and require resourceType
, but you could still have an optional filter
that we'd combine e.g. if a filter
were specified, we'd and
it in parens: resourceType eq "${resourceType}" and (${filter})
.
May elevate using
sudo
on some platforms and configurations
bash:
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535 --version '' --verbose --skip-verify
pwsh:
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535' -Version '' -SkipVerify -Verbose
PowerShell install
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535' -Version '' -SkipVerify -Verbose;"
MSI install
powershell -c "irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/4535/azd-windows-amd64.msi' -OutFile azd-windows-amd64.msi; msiexec /i azd-windows-amd64.msi /qn"
Hey @heaths - i have a very similar PR out. Looks like we both took a very similar route to resolve. https://github.com/Azure/azure-dev/pull/4418
Resolves #4530