-
Notifications
You must be signed in to change notification settings - Fork 517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deployment Issues with Azure PowerShell version 13.0.0 #907
Comments
I've just upgraded to v0.20.0 and I'm now getting this error too. I'm getting it on the following steps:
The first two steps fail, but eventually pass after a number of re-tries, however the last step never succeeds and hence fails the whole pipeline. |
To add, it looks like it's happening on the If I run this locally with the same version of Bicep, it works perfectly. |
I am encoutering this exact issue, too, but only since today. |
Maybe an Azure DevOps runner issue? |
Is someone able to confirm the versions of bicep and the az powershell modules running on their hosted runners to help us troubleshoot further? Might also be worth trying to pin the az powershell module version as per https://github.com/Azure/ALZ-Bicep/wiki/KnownIssues#issue-1-what-if-check-fails-within-azure-devops-pipelinegithub-actions-workflow-with-the-error-additional-content-found-in-json-reference-object-a-json-reference-object-should-only-have-a-ref-property-path-parresourcelockconfigdefaultvalue @Chris031196 @cspring86 @pejuborg Cc: @oZakari |
My versions are:
|
I've been able to test with earlier versions of Bicep with no luck. My suspicion is Az PowerShell 13. |
V13.0.0 came out yesterday 🤷♂️ so I'd put my money there. https://www.powershellgallery.com/packages/Az/13.0.0 Can someone pin to an older version and retry. Say 12.4.0? Following the guidance I shared in the previous comment |
Doing it as we "speak"! The step "Check Az PowerShell Version" is not authored to work with other than the latest version, but the other PowerShell steps seem to. |
Pinning Az PS to 12.5.0 makes the step "Built-in and Custom Policy Assignments Deployment" succeed. |
Pinning the AZ pwsh module to 12.4.0 has worked for me. However, with 13.0.0 on my local machine, it works as well; I can't re-create the issue locally. I've tried in bash and pwsh. |
Thank you, everyone, for reporting the issue and pitching in with troubleshooting—teamwork truly makes the dream work! For now, I’ve updated the Known Issues Wiki with all the information you’ve provided. Starting tomorrow, I’ll dive deeper into troubleshooting this and will also open an issue with the relevant team(s) to get things moving. As it stands, I'm wondering if it's associated to the ADO Azure PowerShell task considering that @cspring86 confirmed it worked fine locally with the latest version. That said, if anyone is using GitHub Actions for their pipelines and running into the same issue, please let me know! |
Hey y'all, we've just hit this same issue in GitHub Actions. Haven't tried to pin the Az-Powershell module yet, but I'm hoping that will fix it here too. |
@jtracey93 Pinning to 12.5.0 does seem to have resolved the issue. |
@awebre Can you try 12.4.0 as that worked for another person in this thread; this'll help us narrow down the issue |
It seems this issue is specific to Azure PowerShell version 13.0.0, as I’ve only been able to replicate it with this version across all three deployment methods (Azure DevOps pipelines, GitHub Actions workflows, and local environments). Versions 12.5.0 and 12.4.0 do not appear to be affected. An issue has been opened in the Azure PowerShell module repository: Azure PowerShell Issue #26752. Additionally, I’ve submitted an internal incident report to Microsoft for further investigation. While I have only been able to replicate this with the ALZ Default Policy Assignments module, others have reported similar deployment failures with other modules. This may depend on specific customizations or parameter configurations. However, my suspicion is that the issue relates to JSON serialization in the ALZ Default Policy Modules, which we use to reference policy assignments. I will provide updates in this thread as more information becomes available from the Azure PowerShell team. |
Could anybody get this to work with self-hosted agents, too? With the not self-hosted agents, on the first deployment step it says in the console output: With self-hosted agents, I just get this:
I even tried to add "Install-Module -Name Az -RequiredVersion 12.5.0" in the script for the "Check Az PowerShell Version" step, which did not make any difference... |
I am seeing the same "Could not find the module path with given version" error on the self-hosted Azure Container agents deployed by the bootstrap process, is there something else that must be updated in the container definitions as well? |
@Chris031196 @russelltomkins - In - name: Install AZ PowerShell
uses: azure/powershell@v2
with:
azPSVersion: 12.5.0
inlineScript: |
Write-Host "Installing AZ PowerShell version 12.5.0" |
Alright, I will try it. I am using Azure DevOps, so my folder structure is a little different. I will add it to my EDIT: aah sorry, of course I cannot add this directly, as the Azure pipelines yaml structure is different. So for me it should be smth like this maybe (?), which I already tried:
|
I added the following PowerShell task as the first task in ".\pipelines\helpers\bicep-installer.yaml" in the Templates repo and things are looking better now. Warning: This task is very slow, my container instance took over 4 mins in whatif stage and 1.5 mins in deploy stage to complete.
|
Apologies, you both referenced self-hosted agents and I gave you a GitHub change. 🤦♂ Let me test that as well to see if there is another way apart from @russelltomkins's approach. |
@russelltomkins is using the correct approach for the self-hosted agents. The Azure DevOps PowerShell task assumes the Az PowerShell module is saved in a specific non-standard directory, /usr/share/az_. By default, PowerShell installs modules to paths like $HOME/.local/share or /usr/local/share, which causes the task to fail if the module isn’t found. Thanks for sharing your solution @russelltomkins! Also, looks like the Azure PowerShell team has a fix committed, we are just waiting on them to create a new release. Also, sounds like the bug has the potential to impact many different types of deployments and is non-deterministic which is why I wasn't able to replicate some of the deployment failures that others in this thread experienced. |
How do I troubleshoot Azure PowerShell / Bicep deployment issues?
I'm struggling to get my Azure DevOps deployment of ALZ-Bicep to work, there are quite a few tweaks that must be done.
My latest hurdle is an error that I don't know how to find the root cause to.
When running the step "Built-in and Custom Policy Assignments Deployment" it fails with the error "Error: Code=; Message=Received unexpected type Newtonsoft.Json.Linq.JObject", and there is nothing that explains what causes this exception.
Code of Conduct
The text was updated successfully, but these errors were encountered: