Open tayganr opened 3 years ago
+1 Can confirm that this was also affecting my environments and deployments over the last few days.
I could not reproduce it with Az.Resources 4.3.1. @tayganr Do you mind checking if upgrading Az.Resources to 4.3.1 fixes the issue?
We started to see the same error in our ADO pipelines:
2021-09-09T16:01:08.5651694Z ##[error]A parameter cannot be found that matches parameter name 'applicationInsightsName'.
2021-09-09T16:01:08.6625784Z ##[error]PowerShell exited with code '1'.
Setting the preferred Azure PowerShell version to 6.3.0 unblocked us.
+1 I can confirm this is also affecting our ADO pipelines. I can also confirm that setting the preferred Azure PowerShell version to 6.3.0 has unblocked us.
I can also confirm that this is affecting our Azure DevOps pipelines. Setting Azure PowerShell version to 6.3.0 resolved the issue for us too
Not sure if this is the same thing but my ARM deployments all stopped working yesterday afternoon, we are using New-AzResourceGroupDeployment @AzResourceGroupDeploymentParams
but yesterday we started getting errors in our build pipeline. The error was:
##[debug]Exception:
##[debug]System.Management.Automation.ParameterBindingException: A parameter cannot be found that matches parameter name 'apiName'.
##[debug] at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
##[debug] at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
##[debug] at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
##[debug] at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
##[debug] at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
##[debug] at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
##[debug] at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
##[debug] at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
##[debug] at System.Management.Automation.CommandProcessorBase.Complete()
##[error]A parameter cannot be found that matches parameter name 'apiName'.
Changing the call to the following fixes the errors in the pipeline
$armOutput = New-AzResourceGroupDeployment -Name "arm-$ProductCode-$ApiName-$Environment-$ResourceGroupLocation-$InstanceId" `
-ResourceGroupName $ResourceGroupName `
-TemplateFile $TemplateFile `
-Verbose `
-TemplateParameterObject $AzResourceGroupDeploymentParams
Not entirely sure what has changed that would have caused this.
Azure PowerShell version 5.185.0
Same here, all pipes on many running projects have suddenly stopped working.
We had the similar issue starting from yesterday in our Azure Devops Pipelines. Setting Azure PowerShell version to 6.3.0 mitigated the issue.
Update: Can also confirm this is resolved in 4.3.1; I guess this version just needs to make it into the Azure DevOps agents 👍
Had this issue in Azure DevOps deployment pipelines at my org. Resolved it by setting PowerShell version to 6.3.0. To do this I modified the build pipeline PowerShell input parameters from having azurePowerShellVersion: LatestVersion to the below:
- task: AzurePowerShell@4
inputs:
...
azurePowerShellVersion: OtherVersion
preferredAzurePowerShellVersion: 6.3.0
Edit: formatting
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @armleads-azure.
Author: | tayganr |
---|---|
Assignees: | - |
Labels: | `Service Attention`, `ARM - Core`, `needs-triage` |
Milestone: | - |
Coul these be related in anyway? https://github.com/Azure/azure-powershell/issues/15841 At least they are created at same day.
We work on Azure Devops and noticed that since this morning 9/16/2021 7:30 (UTC) we where unable to deploy any of our release-definitions. Finally we discovered this was caused by the agent running on ubuntu 20.04 - version: 20210913.1. Our latest successful deployment was done with Ubuntu version 20210906.1. The suggestion by @mperian to use module Az v6.3.0, solved our problem.
Using the -TemplateParameterObject
parameter is a good workaround for this issue.
Instead of:
New-AzResourceGroupDeployment `
-ResourceGroupName $resourceGroupName `
-TemplateFile "$PSScriptRoot\..\arm\template-uai.json" `
-resourceName $userAssignedIdentityName `
-location $location
Use:
$parameters = @{
resourceName = $userAssignedIdentityName
location = $location
}
New-AzResourceGroupDeployment `
-ResourceGroupName $resourceGroupName `
-TemplateFile "$PSScriptRoot\..\arm\template-uai.json" `
-TemplateParameterObject $parameters
We also had similar issue but with Bicep deployment. We didn't change anything in our pipeline YAML files or Bicep files but the pipeline just started to fail. We were using Linux 20.04 Hosted-agent, Azure PS task 5.185.0 with Az 6.1.0.
Updating the az version to 6.3.0 did solve the issue like the others have mentioned.
In our case when we run our pipeline the command just return an error message without much detail.
New-AzResourceGroupDeployment: /home/vsts/work/_temp/55d1c077-6e08-43b8-9d9f-df28c017648e.ps1:12
Line |
12 | … loymentOp = New-AzResourceGroupDeployment -ResourceGroupName $rg -Tem …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Error parsing boolean value. Path '', line 1, position 1.
I tried adding the -Verbose to the New-AzResourceGroupDeployment command. One thing I observed was the command didn't compile the input bicep file before feeding it into the deployment:
...
$deploymentOp = New-AzResourceGroupDeployment -ResourceGroupName $rg -TemplateFile $file -TemplateParameterFile $paramFile -Verbose
VERBOSE: Performing the operation "Creating Deployment" on target "policy-control-reporting-rg".
New-AzResourceGroupDeployment: /home/vsts/work/_temp/7fe4e8bf-66da-4116-a3c1-e2e697224bb9.ps1:12
Line |
12 | … loymentOp = New-AzResourceGroupDeployment -ResourceGroupName $rg -Tem …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Error parsing boolean value. Path '', line 1, position 1.
...
comparing to running the same commands in Cloud Shell without any failure (az 6.3.0):
...
PS /home/tanit> $deploymentOp = New-AzResourceGroupDeployment -ResourceGroupName $rg -TemplateFile $file -TemplateParameterFile $paramFile -Verbose
VERBOSE: Using Bicep v0.4.613
VERBOSE: Performing the operation "Creating Deployment" on target "policy-controlreporting-rg".
...
Seemed like something was updated into Az 6.1.0 and introduced bugs on the command.
We use YAML pipeline and Bicep for our projects to ensure consistency, reliability of our deployment. We also specify a specific version number and not using 'latest'. But there has been a lot of issues caused by something like this. This is not the first time that our pipeline breaks because some bug is introduced from Azure/MS side.
And we are forced to hot fix something again just to fix the issue that weren't there..
Is there a specific resolution to this?
I am not able to move to using the -TemplateParameterObject
easily as I have this running in automation in 4 different Azure tenants so it would mean updating and deploying the automation to all tenants in pre-production and production environments.
I have my Azure function pinned to 2.*
version of Az.Resources
so I am not sure how this has even impacted my project or where the upstream bug lies.
It is easy enough for me to upgrade to a new version of Az.Resources but I will then also have to test this across multiple tenants and environments. This has worked for the past 12 months without issue.
This is a ridiculous regression - it's one thing for Microsoft to ignore new bugs and feature requests, but I would expect some test automation to prevent fundamental breaking defects like this from being released. Especially in the "latest installed version" on Azure pipeline hosts.
I've seen issues like this many times in the ARM + Azure Powershell area, causing many users to waste time and money. I have to assume there's an absence of test automation.
Agreed, we spent lots of hours trouble shooting this on our end while working on some new items... worked a week ago and then broke, so we thought it was something we did... Appears still no fix other than forcing version. We went to 6.3.0 for project we are working on and currently still working. But have lots of other pipelines we will have to update if this is not resolved.
@KorKiak , we heard from some users that similar issue cannot be reproduced anymore. Could you reproduce the issue again? So far, as the team of client side tool, we have no idea what happened. The error message is strange to us. Azure PowerShell has regression test before each PR is merged. The test case on New-AzResourceGroupDeployment didn't detect this problem. More information will be helpful to us.
@KorKiak , we heard from some users that similar issue cannot be reproduced anymore. Could you reproduce the issue again? So far, as the team of client side tool, we have no idea what happened. The error message is strange to us. Azure PowerShell has regression test before each PR is merged. The test case on New-AzResourceGroupDeployment didn't detect this problem. More information will be helpful to us.
I don't have an environment which is currently broken as I had to upgrade my dependencies to get it to work.
The App insights logs where this failed will likely still be around though.
Worth noting that I was executing the Template deployment from an Azure Function at the time.
@KorKiak , we heard from some users that similar issue cannot be reproduced anymore. Could you reproduce the issue again? So far, as the team of client side tool, we have no idea what happened. The error message is strange to us. Azure PowerShell has regression test before each PR is merged. The test case on New-AzResourceGroupDeployment didn't detect this problem. More information will be helpful to us.
Reproducible with just a simple ARM template today. Not sure if i got the right version, but adding this as a datapoint.
(Get-Module -ListAvailable | Where-Object{ $_.Name -eq 'Azure' }) ` | Select Version, Name, Author, PowerShellVersion | Format-List;
Version : 5.1.2 Name : Azure Author : Microsoft Corporation PowerShellVersion : 3.0
@dingmeng-xue - This issue just started happening using standard ubuntu-18.04 Azure DevOps agents, with the New-AzResourceGroupDeployment
running in a script within the Azure Powershell task, version 5.*, using Azure Powershell Version: "Latest installed version". The issue didn't happen before and there were no changes to the deploy script.
The fix was to specify Azure Powershell Version: (Specify Other Version) 6.4.0
Thanks. It seems couple various issues are tangling together. Back to @tayganr original issue, I can reproduce it on Windows PowerShell or PowerShell 7
Az.Accounts (2.5.2) + Az.Resources (4.2.0), works Az.Accounts (2.5.3) + Az.Resources (4.2.0), doesn't work Az.Accounts (2.5.4) + Az.Resources (4.2.0), doesn't work
Az.Accounts (2.5.2) + Az.Resources (4.3.0), works Az.Accounts (2.5.3) + Az.Resources (4.3.0), doesn't work Az.Accounts (2.5.4) + Az.Resources (4.3.0), doesn't work
Az.Accounts (2.5.4) + Az.Resources (4.4.0), works
I suspect Az.Accounts (2.5.3) introduced a change and is not compatible with previous version of Az.Resources. Although no related change happened in Az.Resources, new build 4.4.0 resolved it. We need to investigate it further and avoid it happen again. In addition, we need to check whether we can make upcoming Az.Accounts work with previous version of Az.Resources.
Run your resource monitor and check which browser is doing the hosting. Wave 🌊seems to have some problems and it just might be more in-depth than that since I tried deleting it from the app list (win logo) and it was still in the registry - went to app/in settings - couldn't tell you if it's related to this but its worth a look. Theres more - but later.
We install on our Build Agents Az 6.3.0 currently.
We set up new agents recently which apparently installed Az.Accounts 2.7.0 and Az.Resources 4.3.0 which reproduces the issue as well. Older agents have 2.5.2/4.3.0 respectively which per @dingmeng-xue 's comment do indeed work correctly.
In the process of determining our preferred workaround, but as of today a standard Az 6.3.0 install produces this bug.
Edit 1: Updating to confirm upgrading Az.Resources to 4.3.1 resolves the issue for the Az.Accounts 2.7.0 pairing.
Edit 2: I'm discussing with my team and still testing, but rolling forward to 6.4.0 seems safe for us and pulls in Az.Resources 4.3.1 by default. Rather than monkey patching to stay on 6.3.0 this seems preferred. I'm confused why "upgrading" to 6.3.0 for some folks seemed to fix when that seemed to pull in bad versions for me, but without having access to their environments I can't really say.
Edit 3: Rolling forward hit a new bug unfortunately, so my plan is to snapshot the version I have now and roll that out using offline installation methods. Without an equivalent to package.lock or yarn.lock the version advertised of "Az 6.x" doesn't really have a strong fixed meaning when installed over PowerShellGet / PowerShellGallery, which is unfortunate. Once you have code on a working version having a cache of the package versions is probably wise.
Description
Passing inline parameters to New-AzResourceGroupDeployment no longer works. Tried with multiple ARM templates.
Steps to reproduce
Environment data
Module versions
Error output