Validate locally

hulk check is the fastest way to answer: “Can Hulk safely turn this project into deployable Bicep?”

It runs the complete local project pipeline without authenticating to Azure and without changing .hulk:

1. Loads the selected environment and interpolates variables.
2. Resolves and confines module paths to the project directory.
3. Expands modules, applies skip_envs, and builds the resource index.
4. Validates resource identities, references, and resource-specific rules.
5. Renders into a temporary directory.
6. Compiles the generated template when Bicep is available.

hulk check ./main.json --env dev

Successful checks report the number of resources evaluated and whether the generated Bicep was compiled. Bicep compiler and linter warnings remain visible during local development.

Why use hulk check instead of native ARM validation?

The commands validate different layers. Azure Resource Manager only receives the generated Bicep or ARM JSON template, so it cannot detect problems in Hulk variables, modules, environment filtering, or resource references before transpilation.

Capability	hulk check	bicep build	az deployment group validate
Validates Hulk JSON and resource rules	Yes	No	No
Expands Hulk modules and skip_envs	Yes	No	No
Checks cross-resource Hulk references	Yes	No	No
Compiles and lints generated Bicep	Yes, when installed	Yes	Yes
Checks live Azure provider constraints	No	No	Yes
Requires Azure authentication	No	No	Yes
Writes or replaces .hulk	No	Not applicable	Not applicable

For the normal edit-test loop, hulk check gives earlier and more specific feedback than sending every change to ARM. It renders in an isolated temporary directory, so it cannot accidentally validate an old .hulk/main.bicep or replace a previously deployable artifact.

It is not a replacement for Azure preflight validation. Run hulk plan when the project also needs to be checked against the selected subscription, resource group, registered providers, API versions, permissions, and provider-enforced naming rules.

Bicep compiler behavior

Use --require-bicep in CI so a missing Bicep installation is an error:

hulk check ./main.json --env prod --require-bicep --no-update

Install the compiler ahead of time with az bicep install or place bicep on PATH. Hulk invokes the installed executable directly and never downloads a compiler during check.

Without --require-bicep, Hulk still performs all Hulk-specific validation and warns when the compiler is unavailable. This is convenient for local work. Use --require-bicep in CI to guarantee that Bicep also accepts the generated source.

Inspect generated Bicep

By default, temporary files are deleted after success or failure. Add --keep-artifacts to retain main.bicep and generated modules at the absolute directory path Hulk prints:

hulk check ./main.json --env dev --require-bicep --keep-artifacts

The retained files match the paths and line numbers in compiler diagnostics. .hulk/ remains unchanged. See Debugging generated Bicep for retention behavior, partial output, and cleanup.

CI and editor feedback

Use --no-update for deterministic CI output. Machine-readable errors are available globally:

hulk check ./main.json --env dev --format json
hulk check ./main.json --env dev --format sarif

check never authenticates to Azure, never creates or modifies resources, and never publishes generated files.

What to run next

• Run hulk plan to add live Azure preflight validation or what-if.
• Run hulk transpile when .hulk/main.bicep must be published for a deployment pipeline.
• Run az deployment group create to perform the actual deployment.

See Microsoft’s documentation for az bicep build and ARM preflight validation for the native validation layers Hulk builds upon.