Bicep Insert resource command fails fetching resource #6762
Comments
|
Rolling back the VScode extension to 0.5.6 I can insert resources again successfully. |
|
Are you using anything in your bicepconfig.json file for the e.g. "cloud": {
"currentProfile": "AzureCloud",
"credentialPrecedence": [
// "AzureCLI"
"AzurePowerShell"
]
}It can also be confusing if the terminal is the powershell integrated terminal or the standard terminal, to pickup the fresh credentials, also the difference between powershell 7 versus Windows PowerShell for the login. |
|
@brwilkinson I do not have precedence set in the config file for this project. |
|
Okay @kevball2 without that set it's very hard to track exactly which cred will be used. Since it chains on the list below. The issues comes, that if you were logged into one of these, however the credential is not fresh, it tries to use it and fails. To avoid this either: a) set the credentialPrecedence to the one you are freshly logged into The available credential types are:
Of course, if you are not logged in and you are still seeing issue, we can look further into this one for you, can collect logs from you, however this does tend to be a common side effect, of having so many options available to login with. |
|
No luck unfortunately @brwilkinson,
|
|
Thanks @kevball2 I have also been able to repro this scenario. extension version "credentialPrecedence": [
"AzurePowerShell"
]Also tested with this "credentialPrecedence": [
"AzureCLI",
"AzurePowerShell"
]Also tested with "credentialPrecedence": [
"VisualStudioCode"
]This was all directly after updating the extension version to the latest. it was running in [Info - 2:31:10 PM] Running on processId 44668 gps -id 44668 | select *
Name : dotnet
Id : 44668
Path : c:\Users\benwilk\AppData\Roaming\Code - Insiders\User\globalStorage\ms-dotnettools.vscode-dotnet-runtime\.dotnet\6.0.4\dotnet.exe
CommandLine : "c:\Users\benwilk\AppData\Roaming\Code - Insiders\User\globalStorage\ms-dotnettools.vscode-dotnet-runtime\.dotnet\6.0.4\dotnet.exe" c:\Users\benwilk\.vscode-insiders\extensions\ms-azuretools.vscode-bicep-0.6.1\bicepLanguageServer\Bicep.LangServer.dll
--pipe=\\.\pipe\vscode-jsonrpc-de1accbc315680583e21a5a9640bf935cf43442eab-sock --clientProcessId=22256
Parent : System.Diagnostics.Process (Code - Insiders)
Company : Microsoft Corporation
CPU : 6.390625
ProcessName : dotnetso I figured I would try restarting VSCode all together to test/confirm. Tested again with PowerShell same error. Azure.Identity.CredentialUnavailableException (0x80131500): PowerShell is not installed |
|
Our build pipelines began to fail this week as Bicep v0.6.1 was rolled out on the MS-Hosted Build Images (ubuntu-20.04) in Azure Pipelines. We make the use of Template Specs and started getting this error with Bicep v0.6.1. We were able to work around the issue by overriding the (now-default) Bicep version with the previous version (v0.5.6). Error message for reference: |
|
+1 I`m authenticated using the same user account in Azure CLI, Azure PowerShell, and the VS Code extension. I can perform actions such as list resources using all 3 tools, so authentication should be fine. Regardless, the error is the same when trying to use the "Bicep: Insert resource" function. This is reproed on both MacOS and Windows 11. Would trying MSAL instead of ADAL be worth a shot?
I only see this option on the Windows machine though, so not sure what is used on MacOS. |
|
@brwilkinson since you're able to repro this, I'd like to rule out the Azure.Identity package upgrade as the cause of this issue. Would you mind testing with the VSIX extensions attached to the following releases:
If "before" succeeds and "after" fails, then I think it's likely to be related. |
|
@anthony-c-martin Unfortunately both of these versions are still working for me. Both of these work.vsix: [email protected] also worksvsix: [email protected] Moving back to latest does not work. |
|
Sorry, you only need to run chmod if the downloaded file didn't already exist. |
|
@pb111111 Thanks. Even after removing the CHMOD statements the original error still persists. I'll look further into why that worked for you but not for us. I hope microsoft rolls back the bicep version on their agents or manages to somehow fix forward a bicep version that works. Update: Microsoft support suggested a similar approach which also does not work. |
|
After the workaround, this the output of bicep-v printed right before the what-if Bicep CLI version 0.5.6 (5f2f88f) Notice the version! the powershell workaround by @pb111111 correctly replaces the version, but then the consecutive azure deployment does not seem to use that bicep version? |
|
@brwilkinson - I narrowed the issue down to between these two builds:
So it seems like this issue was introduced with this commit: 14fd377 I'll keep digging, but it would be great if you have the time to confirm that you see the same |
|
@anthony-c-martin confirmed the failure and I can see the
should be:
This is also visible in the above logs ealier in the thread. |
|
@brwilkinson great spot! @bhsubra would you mind taking a look? |
|
We'll be publishing a new Bicep release shortly with the fix! |
|
This issue should be fixed with today's 0.6.11 release. Let us know if there are any concerns. Thanks! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bicep version
run
bicep --versionvia the Bicep CLI,az bicep versionvia the AZ CLI or via VS code by navigating to the extensions tab and searching for BicepBicep CLI version 0.4.1272 (a69022d) PS
Bicep plugin - v0.6.1
powershell - 7.2.3
AZ CLI - 2.36.0
Describe the bug
When attempting to insert a new resource into a bicep file I receive the attached error.
To Reproduce
ctrl + shift + P to open vscode pallet - run Bicep: Insert Resource
Choose any resource ID and attempt to add. Error occurs
Additional context
See attached screen shot of error
attempted in multiple bicep files with 2 different resources.
I confirmed I was logged in az login as well as logged in with powershell
The text was updated successfully, but these errors were encountered: