Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bicep build intermittently transpiles the same Bicep file to a different ARM template #16332

Open
jurjenoskam opened this issue Feb 5, 2025 · 0 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@jurjenoskam
Copy link

Bicep version
0.32.4 and later (latest tested 0.33.93). The problem did not occur with earlier Bicep versions.

Describe the bug
Repeatedly building the same Bicep file intermittently results in syntactically different (but semantically identical) ARM templates. Even though the result is semantically identical, this breaks our workflow as we use the calculated templateHash to check whether an automatically built template is identical to a published template.

The difference is in the order of dependencies of a resource, but it does not happen with every resource. For a relatively big template, the only difference is in this fragment:

      "dependsOn": [
        "cMKKeyVault::cMKKey",
        "cMKManagedDiskKeyVault::cMKKey",
        "cMKKeyVault",
        "cMKManagedDiskKeyVault"
      ]

...which sometimes appears in the ARM template as (note the difference in the order of dependencies):

      "dependsOn": [
        "cMKManagedDiskKeyVault::cMKKey",
        "cMKKeyVault::cMKKey",
        "cMKKeyVault",
        "cMKManagedDiskKeyVault"
      ]

To Reproduce
I've found that this has to do with the state of the Bicep template spec cache. If the cache is empty, the resulting ARM template has a chance of containing the second snippet above, although it will often contain the first snippet. If the cache is populated, the resulting ARM template always contains the first snippet, never the second. The strange thing is that in all cases the resulting files in the cache are 100% identical.

To demonstrate the intermittent behavior when starting with a fresh cache every build:

$ while true ; do rm -rf ~/.bicep/ts && bicep build main-with-metrics.bicep && md5sum main-with-metrics.json ; done
7a4409f980df7adb51fde5d76ddccf7a  main-with-metrics.json
7a4409f980df7adb51fde5d76ddccf7a  main-with-metrics.json
7a4409f980df7adb51fde5d76ddccf7a  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
7a4409f980df7adb51fde5d76ddccf7a  main-with-metrics.json
7a4409f980df7adb51fde5d76ddccf7a  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json

To demonstrate that if the cache is full when Bicep starts, the result is always the same:

$ rm -rf ~/.bicep/ts && while true ; do bicep build main-with-metrics.bicep && md5sum main-with-metrics.json ; done
7a4409f980df7adb51fde5d76ddccf7a  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json
87fdeecdc4f784d7456a1b9b7a95aecf  main-with-metrics.json

Additional context
A workaround is to to a bicep restore --force first, and then bicep build. As the cache is populated before the build starts, the problem doesn't occur.

Unfortunately I can't supply the source template, as it contains some deploymentScripts and other sensitive data, and I haven't been able to narrow down the problem to a simpler template yet. For what it's worth, the problematic template is a languageVersion 2 template.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Todo
Development

No branches or pull requests

3 participants