Make helix-inner-step send job warnaserror the same between windows and non-windows platforms#86729
Conversation
…end to helix step.
This reverts commit ba06e85.
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsThis PR adds warnaserror false when using the send-to-helix-inner-step.yml on non-windows systems. warnaserror 0 is already being used for the same step for windows systems so this brings these two steps into parity. @trylek Are you aware of any reason's to not use the same warnaserror values on non-windows systems as the windows system? Any thoughts on this change are appreciated! Background: Our performance pipelines are getting warnings about some queues being removed soon which we are already dealing with. However, jobs targetting MacOS queues are having the removal warning populate as an error hiding the actual results from the jobs.
|
trylek
left a comment
There was a problem hiding this comment.
I don't recall anything fundamental off the top of my head, your change looks good to me, perhaps it might be useful to double-check with someone on Mono like @naricc if there's not a subtle catch that might need this behavioral difference.
caaavik-msft
left a comment
There was a problem hiding this comment.
It seems before this, warnaserror was set to false for the Windows build step and the non-Windows restore step. This PR only adds it to the non-Windows build step, should we also set it for the Windows restore step while here to ensure both are in sync?
That makes sense. Added warnaserror 0 to the windows restore. Perf pipeline test run: https://dev.azure.com/dnceng/internal/_build/results?buildId=2188271&view=results |
|
Test run ran as expected, merging. |
This PR adds warnaserror false when using the send-to-helix-inner-step.yml on non-windows systems. warnaserror 0 is already being used for the same step for windows systems so this brings these two steps into parity.
@trylek Are you aware of any reason's to not use the same warnaserror values on non-windows systems as the windows system? Any thoughts on this change are appreciated!
Background: Our performance pipelines are getting warnings about some queues being removed soon which we are already dealing with. However, jobs targetting MacOS queues are having the removal warning populate as an error hiding the actual results from the jobs.
Test run here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2187577&view=logs&j=8acf73da-ca1d-50e8-cd01-44779728784d&t=3c7febe5-578c-5a7c-1582-f61ec279ce08