Ignoring the template, sorry.
So, ALOpsInfo v3 does a bunch of really cool checks, and I love that.
But, every check should be surfaced as a controllable element. For example, I have build servers that are super optimized and run multiple agents just fine, but that gives me a warning I can't disable.
The problem is, ADO considers "success with errors" as different from "Success" for the purposes of which "Work Items" are included in the Pipeline run.
With this new step where I have warnings I can't silence, this will break my policies about "Success with Warnings is a Failure, fix it".
While in there, I was also running into an issue where it tried to update BcContainerHelper - the agent is running as a local admin, but the powershell isn't running elevated, so the Update-Module call gives an error. This check can't be skipped, or changed to just a "Warning but proceed", so it's another "to control"
Ignoring the template, sorry.
So, ALOpsInfo v3 does a bunch of really cool checks, and I love that.
But, every check should be surfaced as a controllable element. For example, I have build servers that are super optimized and run multiple agents just fine, but that gives me a warning I can't disable.
The problem is, ADO considers "success with errors" as different from "Success" for the purposes of which "Work Items" are included in the Pipeline run.
With this new step where I have warnings I can't silence, this will break my policies about "Success with Warnings is a Failure, fix it".
While in there, I was also running into an issue where it tried to update BcContainerHelper - the agent is running as a local admin, but the powershell isn't running elevated, so the Update-Module call gives an error. This check can't be skipped, or changed to just a "Warning but proceed", so it's another "to control"