Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Write the what-if result to a JSON file (`what-if-output-file` input)

Open
  • Is something wrong?
#347 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
azure, github-actions, typescript
Domain
ci-cd, cloud

Research direction

Start with the what-if handler in the bicep-deploy-common package, which already takes an OutputSetter, and trace how the what-if result reaches the step output for operation: whatIf. Settle the file contents first: the ARM REST body or JSON.stringify of the SDK result, which the issue leaves open. Done means the what-if-output-file input writes the file only when a result comes back, including Failed status, and sets the output path. Nothing is written on auth, compile, or input errors.

Written by the indexing model from the issue text.

Description

Background

Following up on the suggestion in #327 to track this separately.

Today the what-if result exists only as formatted text in the step log. Several issues ask to use it elsewhere:

  • #155: put it in the workflow summary, a PR comment, or an artifact
  • #227: same ask, per the later comments
  • #322: control the result format

A machine-readable copy of the result would cover all of these with one primitive, and leave rendering to the workflow.

Feature request

An optional input that writes the what-if result to a JSON file, plus an output that returns its path. It would apply to operation: whatIf for both type: deployment and type: deploymentStack (once #327 lands).

- id: whatif
  uses: azure/bicep-deploy@v2
  with:
    type: deployment
    operation: whatIf
    what-if-output-file: ${{ runner.temp }}/what-if.json
    ...

- run: jq '.properties.changes | length' "${{ steps.whatif.outputs.what-if-output-file }}"

In BicepDeploy@0 this would be whatIfOutputFile. The handler in bicep-deploy-common already takes an OutputSetter, so most of the work would land once for both.

Behavior

  • Not set: no change from today.
  • The what-if returns a result: write it, including when its status is Failed (the body carries error).
  • No result comes back (auth, compile or input errors): write no file and leave the output unset. Combined with hasChanges from #327, a step with continue-on-error can tell "no changes" apart from "never ran".

Open question: what goes in the file

I'd suggest the ARM REST response body, if the SDK makes that practical. That shape is documented and versioned by api-version, so consumers can rely on it. The serialized SDK model can differ (Date objects, flattened or renamed properties) and could change with SDK upgrades. If the raw body isn't practical, JSON.stringify of the SDK result is still far better than parsing log text.

Contribution

I'm happy to send a PR for the common package and the action once the input/output shape is agreed. For context, I maintain an Azure DevOps extension that renders what-if results in the pipeline UI, and today it has to run what-if again itself to get the data.

Dominant language
TypeScript
Stars
66
Forks
20
Avg merge
10h 16m
Merged PRs (30d)
16

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Azure/bicep-deploy

All issues in Azure/bicep-deploy

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.