feat: Add input parameter to bicep build command that allows suppressing verbosity during execution

[AlexanderSehr]

Working recently on troubleshooting why something like $templatePaths | Foreach-Object -Parallel { bicep build $_ } would work for some Bicep templates but not for others I found out that the vebosity of the bicep build command seems to conflict with this kind of multithreading on Linux pipeline agents (I'm not able to reproduce this locally neither on Windows nor the WSL) - consistently.

The verbosity I'm referring to specifically are warnings returned by the template. For example /home/runner/work/bicep-registry-modules/bicep-registry-modules/avm/res/operational-insights/workspace/saved-search/main.bicep(44,5) : Warning BCP037: The property "etag" is not allowed on objects of type "SavedSearchProperties". No other properties are allowed. If this is an inaccuracy in the documentation, please report it to the Bicep Team. [https://aka.ms/bicep-type-issues] which is, unforatuntely, a false positive.

What happens using the above command is, that bicep build starts running in a thread, it prints the warning, and then the code goes into an 'error' state without an actual error to show for. To find out that it's because of the verbosity took a while:

While there is a 'workaround', that is, adding #disable-next-line to any line in question, there is a fair chance these issues will return each time e.g. the Bicep linter rules are updated.

To solve this for cases where I'm not interested in this verbositry (e.g., when I just want to build a dozen templates to statically test them) it would be very helpful if there would be a parameter to prevent the command from trying to write anything to the output/console stream. For example bicep build <path> --no-verbose.

[AlexanderSehr]

This may or may not be related to #2334

[anthony-c-martin]

It sounds like the powershell script or your CI pipeline is treating stderr as an indication that the command has failed? I would recommend instead checking the exit code to determine success or failure, and allowing stderr to be written to the normal error output channel.

If you're just looking to suppress stderr, then using 2> is a standard mechanism for doing this.
Powershell:

bicep build main.bicep --stdout 2>$null

Bash:

bicep build main.bicep --stdout 2>/dev/null

[AlexanderSehr]

Dear @anthony-c-martin , thank you for the swift reply. Let me give that a shot. :)

[AlexanderSehr]

So... the Bicep command really didn't like the --stderr: Unrecognized parameter "--stderr" :D Hence I'm not entirely sure how to check the exit code on this one.

Nethertheless - it did allow us to get past the issue. Thank you @anthony-c-martin :) If you happen to have a pointer regarding the stderr, let me know. :)

[anthony-c-martin]

@AlexanderSehr I'll start by saying that I'm not a powershell expert. Generally, there are 3 things to check when you invoke a process: stdout, stderr, exit code.

My recommendation would be:

• Check the exit code ($LASTEXITCODE in powershell) if you want to determine overall "Did the file compile successfully?"
• You're already using stdout to capture the generated bicep file, which makes sense
• Capture stderr and log it somewhere (this may help with troubleshooting - otherwise you may have a hard time understanding why a given file failed to build in the future)

Example of the approach I followed for accomplishing something similar in C# here:

• Capture stdout & stderr to a variable
• Check the exit code:
  • If 0, return the stdout, and log stderr to the "warning" channel
  • If non-0, throw an exception, and include stderr in the exception (to ensure it's logged)

Personally I'm not a PowerShell expert, so I'd have to defer to someone else to recommend how to accomplish this in Pwsh.