Warning from Bicep results in failed action

[hansmbakker]

When setting bicepconfig.json to the following

{
  "experimentalFeaturesEnabled": {
    "userDefinedTypes": true
  }
}

Bicep will warn about using an experimental feature. However, the azure/arm-deploy action interprets this warning as an error and fails the whole run, even though the actual deployment went well:

Run azure/arm-deploy@v1
Changing subscription context...
Validating template...
Warning: WARNING: WARNING: Symbolic name support in ARM is experimental, and should be enabled for testing purposes only. Do not enable this setting for any production usage, or you may be unexpectedly broken at any time!

Creating deployment...
Error: WARNING: WARNING: Symbolic name support in ARM is experimental, and should be enabled for testing purposes only. Do not enable this setting for any production usage, or you may be unexpectedly broken at any time!

Error: Deployment process failed as some lines were written to stderr

Using failOnStdErr: false feels like a too harsh workaround because then there is no possibility anymore to distinguish between a warning and a real error.

[rdeveen]

The same happen when there is an update of the Bicep CLI available. This warning should not result in an error.

Warning: WARNING: A new Bicep release is available: v0.20.4. Upgrade now by running "az bicep upgrade".

Creating deployment...
Error: WARNING: A new Bicep release is available: v0.20.4. Upgrade now by running "az bicep upgrade".

Error: Deployment process failed as some lines were written to stderr

[Kaloszer]

+1

[hoffe86]

+1

Any updates or workaround?

[jefedeltodos]

+1

My only workaround to ignore this false fail is to add a continue-on-error: true, and the job will complete successfully.

The issue with this workaround is the job will still succeed even if a legitimate error happens with the deployment.

🤷

[anthony-c-martin]

Using failOnStdErr: false feels like a too harsh workaround because then there is no possibility anymore to distinguish between a warning and a real error.

It should be safe to set this to false (in fact, I really think this should be the default, or we should just remove the option entirely).

We check the AzCLI exit code to determine failure, which is a more reliable source: https://github.com/Azure/arm-deploy/blob/732d82b8bca98e44ee8972c4a8d279efc12d65d1/src/utils/azhelper.ts#L65-L67