Skip to content
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

Merged
1 commit merged into from
Oct 31, 2022

Conversation

benbp
Copy link
Member

@benbp benbp commented Oct 27, 2022

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.

@benbp benbp added the Central-EngSys This issue is owned by the Engineering System team. label Oct 27, 2022
@benbp benbp self-assigned this Oct 27, 2022
@azure-sdk
Copy link
Collaborator

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

New-AzResourceGroupDeployment -Name $BaseName -ResourceGroupName $resourceGroup.ResourceGroupName -TemplateFile $templateFile.jsonFilePath -TemplateParameterObject $templateFileParameters -Force:$Force
} catch {
Write-Output @'
New-AzResourceGroupDeployment `
Copy link
Member

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?

Copy link
Member

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.

Copy link
Member Author

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...)

Copy link
Member Author

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?

Copy link
Member

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') {
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@weshaggard weshaggard left a 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 `
Copy link
Member

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.

@ghost
Copy link

ghost commented Oct 31, 2022

Hello @azure-sdk!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit fcc496a into Azure:main Oct 31, 2022
@benbp benbp deleted the benbp/remove-deployment-logging branch October 31, 2022 21:24
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Central-EngSys This issue is owned by the Engineering System team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants