Skip to main content
Use this tutorial when your team authors infrastructure in Bicep and needs predictable analysis workflows.

​
Why it matters

Bicep workflows can vary by environment. A clear fallback path prevents blocked onboarding.

​
Quick example

# Convert bicep to ARM JSON when needed
az bicep build --file main.bicep --outfile main.json
Expected output: A generated ARM template (main.json) you can upload through the standard path.

​
Step-by-step instructions

  1. Validate your Bicep file compiles.
  2. Start with a small module set.
  3. Test ingestion in CloudEval.
  4. If parsing is inconsistent, convert to ARM JSON and continue.
  5. Compare resulting graph output for parity.

​
Code examples

az bicep build --file infra/main.bicep --outfile infra/main.json

cloudeval ask "List resources and dependencies" --project <project_id>

​
Expected output

  • Successful compile to ARM JSON.
  • Project ingestion succeeds through ARM-compatible flow.
  • Diagram and chat respond with expected resources.

​
Common mistakes

  • Assuming every Bicep construct has identical ingestion behavior.
  • Skipping compile validation before upload.
  • Mixing unsupported modules without fallback.

​
Tips / best practices

  • Keep a stable ARM fallback for incident response.
  • Validate Bicep changes in CI before CloudEval upload.
  • Track Bicep constraints in your team’s onboarding notes.
Last modified on March 5, 2026