Open martinjanocko opened 10 months ago
@martinjanocko We won't be able to figure out the root cause without more detailed logs. Could you set the following environment variables before running the command that is failing?
BICEP_TRACING_ENABLED: True
BICEP_TRACING_VERBOSITY: Full
hi, running the latest Bicep CLI version 0.25.53 (c0ad57dff6) i am no longer able to reproduce this issue. thanks for your help!
Thanks for confirming!
@majastrz even though i could not reproduce the issue locally, it surfaced again in one of our deployment pipelines.
the setup is:
main.bicep
- br:<redacted>.azurecr.io/bicepmodules/storageaccount:default
- br:<redacted>.azurecr.io/bicepmodules/keyvault-add:default
- br:<redacted>.azurecr.io/bicepmodules/auto-serviceplan:default
- function.bicep
- br:<redacted>.azurecr.io/bicepmodules/functionapp-v2:default
calling restore
az bicep install --version v0.25.53
$env:BICEP_TRACING_ENABLED = "True"
$env:BICEP_TRACING_VERBOSITY = "Full"
az bicep restore --file main.bicep --force --debug
For each bicep module i can see TRACE: Authenticated attempt to pull artifact ..
except for the functionapp-v2
referenced in functionapp.bicep
file.
Task log attached with debug and tracing enabled. restore-task.log
If you could have a look that would be greatly appreciated. Thank you!
It appears that we are not even attempting to restore br:<redacted>.azurecr.io/bicepmodules/functionapp-v2:default
. I attempted to recreate the project structure on my end and was unable to reproduce the behavior 😟.
bicep build
instead of bicep restore
? Are there any build errors or warnings?Hi, I can't reproduce this locally. This issue appears when running Azure pipeline on MS hosted agent with vmImage: windows-latest
and the az bicep restore
is part of a AzureCli task. I have not tested private agents, different image or tasks.
bicep build
works as expected, no errors and trace contains TRACE: Authenticated attempt to pull artifact for module br:<redacted>.azurecr.io/bicepmodules/functionapp-v2:default.
From further testing it seems like the --force
parameter causes the issue. Calling az bicep restore --file main.bicep
succeeds as expected and trace logs contain TRACE: Authenticated attempt to pull artifact for module br:<redacted>.azurecr.io/bicepmodules/functionapp-v2:default.
Bicep version > az bicep version
Bicep CLI version 0.23.1 (b02de2da48)
> az --version azure-cli 2.55.0
core 2.55.0 telemetry 1.1.0
Dependencies: msal 1.24.0b2 azure-mgmt-resource 23.1.0b2
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe' Extensions directory 'C:\Users\work.azure\cliextensions'
Python (Windows) 3.11.5 (tags/v3.11.5:cce6ba9, Aug 24 2023, 14:21:31) [MSC v.1936 32 bit (Intel)]
Describe the bug When running
az bicep restore -f .\main.bicep --force
following error is displayed:When running
az bicep restore -f .\main.bicep
the modules are restored as expected.I am successfully logged in with
az login
. Deleting cache at%USERPROFILE%\.bicep\br\
does not seem to make a difference.To Reproduce Steps to reproduce the behavior:
az bicep restore -f .\main.bicep --force
with main.bicep containing a reference to azure registry.Additional context