Azure CLI with Bicep works differently

[justinyoo]

Hi, Team.

When I added the azure-cli feature to the devcontainer settings, I enabled the following option:

• "installBicep": true

Because it's a part of Azure CLI option, I was expecting that I would be able to use the following command:

az bicep version

However, it doesn't work. Rather it works in the following way:

bicep --version

It means that the Bicep CLI works as a standalone CLI instead of the part of Azure CLI. And I found the following codebase:

features/src/azure-cli/install.sh

Lines 205 to 208 in 7fa9011

	# Properly install Azure Bicep based on current architecture
	# The `az bicep install` command installs the linux-x64 binary even on arm64 devcontainers
	# The `az bicep install --target-platform` could be a solution; however, linux-arm64 is not an allowed value for this argument yet
	# Manually installing Bicep and moving to the appropriate directory where az expects it to be

Is there a reason that we use the standalone Bicep CLI, rather than Azure CLI integrated one?

[samruddhikhandale]

bicep is accessed with bicep --version and az bicep version.

Repro 👇

"features": {
    "ghcr.io/devcontainers/features/azure-cli:latest": {
      "installBicep": "true"
    }
  }

@justinyoo Are you passing any other option to this Feature? Could you help with repro steps and your dev config. If you add machine info details along with VS Code version, Extension details would be great.

[justinyoo]

I use this devcontainer.json file

https://github.com/devkimchi/power-platfform-connector-via-apim/blob/main/.devcontainer/devcontainer.json

The main difference from yours is that I use the tag of :1 and yours is :latest.

The latest version of this feature is 1.0.7. Does :1 recognise the latest version?

[samruddhikhandale]

Does :1 recognise the latest version?

Yes, we use semantic versioning. Hence, all points to the same artifact.

@justinyoo Your postcreatCommad is reinstalling bicep here. I wonder if that's causing the problem?

ℹ️ We have bumped the major version for common-utils to 2 with support for Debian/Ubuntu, RHEL/Fedora/Rocky/CentOS, and Alpine Linux! Alsim. Alos, we have renamed uid & gid option to fix a bug. You may want to switch to that?

#326

[justinyoo]

@justinyoo Your postcreatCommad is reinstalling bicep here. I wonder if that's causing the problem?

Yes, I do install bicep manually through post-create.sh because Azure CLI feature installs bicep differently.

ℹ️ We have bumped the major version for common-utils to 2 with support for Debian/Ubuntu, RHEL/Fedora/Rocky/CentOS, and Alpine Linux! Alsim. Alos, we have renamed uid & gid option to fix a bug. You may want to switch to that?

Oh, let me try that!

[justinyoo]

@samruddhikhandale I'm still getting the same issue.

[samruddhikhandale]

Identified the bug, looks like _REMOTE_USER_HOME in here is not always correct.

These are the values when the azure-cli Feature is executed in your dev config👇

The value of _REMOTE_USER_HOME should have been /home/vscode

Opened a bug in devcontainers/cli#331

[samruddhikhandale]

Yes, I do install bicep manually through post-create.sh because Azure CLI feature installs bicep differently.

Created a PR with a temporary alternate solution to unblock you - devkimchi/power-platform-connector-via-apim#1

[samruddhikhandale]

Closing in favor of devcontainers/cli#331
Fixing the CLI bug would automatically fix this.

[justinyoo]

@samruddhikhandale Hmmm. I don't see the fix yet. I still have to manually install bicep through the command az bicep install.