-
Notifications
You must be signed in to change notification settings - Fork 183
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
Dump out correlation id without verbose logging for resource deployment #4532
Conversation
The following pipelines have been queued for testing: |
New-AzResourceGroupDeployment -Name $BaseName -ResourceGroupName $resourceGroup.ResourceGroupName -TemplateFile $templateFile.jsonFilePath -TemplateParameterObject $templateFileParameters -Force:$Force | ||
} catch { | ||
Write-Output @' | ||
New-AzResourceGroupDeployment ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the old code it would seem as though this might throw exceptions if it failed. Do you know if that is true or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it could throw or return an error- try...catch...finally
in powershell works for both. The idea was to reset the $DebugPreference
, which we don't need anymore. Why it kept going I don't know - might've been an oversight after all the changes in this area over the years.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does throw still, which gets caught by the Retry
function handler instead. I was confused at first as well (though it was my old code so...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess Retry only exits with a Write-Error, so perhaps we should actually re-throw in case the ErrorActionPreference is different for local users?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could work.
There are some ill-behaved cmdlets like this that actual throw instead of write error, including the first-party Invoke-WebRequest
(which just bit me today; I had no idea it wasn't...proper).
-Force:$Force | ||
} | ||
|
||
if ($deployment.ProvisioningState -ne 'Succeeded') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully explicitly checking for succeeded will help handle some error cases that were slipping through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we weren't handling non-succeeded states any differently before. IIRC we saw some issues with the state being Incremental
or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the one question about exceptions this looks good.
New-AzResourceGroupDeployment -Name $BaseName -ResourceGroupName $resourceGroup.ResourceGroupName -TemplateFile $templateFile.jsonFilePath -TemplateParameterObject $templateFileParameters -Force:$Force | ||
} catch { | ||
Write-Output @' | ||
New-AzResourceGroupDeployment ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it could throw or return an error- try...catch...finally
in powershell works for both. The idea was to reset the $DebugPreference
, which we don't need anymore. Why it kept going I don't know - might've been an oversight after all the changes in this area over the years.
Hello @azure-sdk! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
We don't really need this verbose logging anymore. Removing it to save log space, as well as mitigate potential issues in the NET storage pipelines where the log output gets truncated, meaning pipeline variables don't get set.