Github azure/arm-deploy actions fails when a new bicep version is available

Question

The github action fails when using github action azure/arm-deploy to deploy a bicep template on a github hosted agent because bicep writes an output to stderr indicating there is a new version. The action fails as soon as something was send to stderr.

I have seen this behavior a couple of days back when bicep was upgraded from v0.13.1 to v0.14.6. Today I encounter the same when upgrading to v0.14.46. The only thing I was able to do at that time was waiting until the latest version of bicep was available (luckily it lasted less then a day before the hosted-agents were updated with the latest bicep version).

While trying more, I noticed that some action pipelines succeeded. This was probably because agents were getting updated and I was just lucky to have an agent with the latest bicep version.

Is there a way I can circumvent this? Can I deploy a bicep template even if the github hosted agent is not on the latest bicep version?

Following has been tried:

I added a step in the pipeline to deploy a specific bicep version. This didn't seem to work; the bicep version available on the hosted agent was taken (making multiple runs resulted in a random Bicep version, depending on what's available on the agent).
Setting failOnStdErr: false (property on azure/arm-deploy) had no effect and is not prefered because I want to be informed if a bicep deployment failed or not.

jessehouwing · Answer 1 · 2023-06-13T10:52:47.503

1

There's a few options, run any of these before the arm-deploy task.

Upgrade bicep in your workflow. Add:
```
steps:
- run: az bicep upgrade
```

Turn off update checking:

steps:
- run: az config set bicep.check_version=False

Don't let az pick the bicep from the path:

steps:
- run: az config set bicep.use_binary_from_path=false

edited Jun 13 '23 at 10:52

answered Feb 09 '23 at 15:53

jessehouwing

106,458
22
256
341

As described, step 1 was tried before and didn't work out. I added step 2 and didn't have the issue ever since. Though I must say that I wasn't assigned a hosted agent anymore. Lets see what new bicep releases bring ... – Thomas Houtekier Feb 10 '23 at 09:46
Try adding: `az config set bicep.use_binary_from_path=false` – jessehouwing Feb 10 '23 at 17:46
1

The command that worked for me was `az config set bicep.check_version=False`. `version_check` didn't work. – Iouri Simernitski - MSFT Jun 13 '23 at 00:49
In that case the docs need an update: https://learn.microsoft.com/en-us/cli/azure/bicep?WT.mc_id=DOP-MVP-5001511&view=azure-cli-latest – jessehouwing Jun 13 '23 at 08:30
See: https://github.com/Azure/azure-cli/pull/26662 – jessehouwing Jun 13 '23 at 10:53
@jessehouwing why does this work and what does it do together with upgrade? `az config set bicep.use_binary_from_path=false` – discy Aug 07 '23 at 19:13
It prevents az from potentially picking up a version that's installed on the agent by default and seperately from then cli. – jessehouwing Aug 07 '23 at 20:16

Github azure/arm-deploy actions fails when a new bicep version is available

1 Answers1