If Bicep returns a non-0 exit code (e.g. there are any build errors), not propagating output

[johnnyreilly]

Describe the bug

@anthony-c-martin of the Bicep team asked me to raise this issue here:

Azure/bicep#11960 (comment)

This issue being experienced is that when az bicep lint fails (returns a non-0 exit code) no output is produced.

Related command

Consider the following command that lints a Bicep module and outputs to a bicep.sarif file:

az bicep lint --file ./infra/main.bicep --diagnostics-format sarif > bicep.sarif

This works well when it comes to lints that exit with 0 (only warnings). Output is produced, this is as desired. However if the linting fails / exits with non-0 then output is not produced. This is a problem as users are not advised as to the problem.

Errors

Haha - it's actually the lack of errors that is the issue!

Issue script & Debug output

Running in the context of GitHub Actions:

      - name: Lint Bicep
        if: github.event_name == 'pull_request'
        uses: azure/CLI@v1
        with:
          inlineScript: |
            az bicep install
            az bicep version
            az bicep lint --file ./infra/main.bicep --diagnostics-format sarif > bicep.sarif
            echo '::warning::Bicep linting results:'
            cat bicep.sarif

With a bicepconfig.json that looks like this:

{
  // See https://aka.ms/bicep/config for more information on Bicep configuration options
  // Press CTRL+SPACE/CMD+SPACE at any location to see Intellisense suggestions
  "analyzers": {
    "core": {
      "rules": {
        "no-unused-vars": {
          "level": "error"
        }
      }
    }
  }
}

And in the main.bicep file an unused variable:

var unusedVar = 1 

This produces no output. See here: https://github.com/johnnyreilly/blog.johnnyreilly.com/actions/runs/7684802835/job/20941714974?pr=817

Error: Error: az cli script failed.
cleaning up container...
MICROSOFT_AZURE_CLI_1706434089539_CONTAINER

Error: az cli script failed.

Expected behavior

By contrast compare with https://github.com/johnnyreilly/blog.johnnyreilly.com/actions/runs/7684722135/job/20941552998 where there was a 0 return code as we dialled the lint rule down from an error to a warning:

{
  "$schema": "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.6.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "bicep"
        }
      },
      "results": [
        {
          "ruleId": "no-unused-vars",
          "message": {
            "text": "Variable \"unusedVar\" is declared but never used. [https://aka.ms/bicep/linter/no-unused-vars]"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file:///home/runner/work/blog.johnnyreilly.com/blog.johnnyreilly.com/./infra/main.bicep"
                },
                "region": {
                  "startLine": 19,
                  "charOffset": 5
                }
              }
            }
          ]
        }
      ],
      "columnKind": "utf16CodeUnits"
    }
  ]
}

Regardless of whether exiting with 0 or non-0, az bicep lint should produce output.

Environment Summary

{
  "azure-cli": "2.56.0",
  "azure-cli-core": "2.56.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {}
}

Additional context

Read more from the thread here: Azure/bicep#11960 - there's a bunch of things in there

[yonzhan]

Thank you for opening this issue, we will look into it.

[torreymicrosoft]

Thanks for your patience, @johnnyreilly — this was recently picked up as an outstanding open issue for the ARM Deployments team to review (and thanks to @anthony-c-martin for routing it over from Azure/bicep#11960).

Reproduced on current CLI (2.85.0). With an error-level rule:

# bicepconfig.json: no-unused-vars => "error", main.bicep has an unused var
az bicep lint --file main.bicep --diagnostics-format sarif > bicep.sarif
# exit 1, bicep.sarif is 0 bytes, stderr is just "ERROR:"

Flip the same rule to warning and the SARIF is written as expected. So you've pinpointed it exactly: when the underlying Bicep process exits non-zero, the azure-cli wrapper raises and discards the captured stdout instead of forwarding the diagnostics, which is precisely the diagnostics you most need on a failed lint. (It's also the same swallow that produces the unhelpful bare ERROR: people see elsewhere.)

This is an azure-cli-side fix — the wrapper should emit the captured stdout/stderr even on a non-zero Bicep exit.