[Bug]: heroku-cli broken on Apple Silicon host

[rhysb27]

Feature id and version

ghcr.io/devcontainers-extra/features/heroku-cli:1.0.4

Dev Container base Image

ghcr.io/rails/devcontainer/images/ruby:3.4.3

What happened?

Attempting to invoke the Heroku CLI (e.g. heroku -v) causes the following error:

qemu-arm: Could not open '/lib/ld-linux-armhf.so.3': No such file or directory

Nothing in the Dec Containers log output suggests a problem.

I've tried almost every other installation method described in the Heroku CLI Docs to limited avail. The most success I've had has been with the NPM install, but this appears to be discouraged and installs an outdated/"unupdateable" version of the CLI. (That, and I have no other need for Node in my setup, so it seems like unneccesary bloat when the the heroku-cli devcontainer already exists.)

Setup

• M1 Macbook
• Container uses a non-root user
• Base image uses Debian (Bookworm)
• Docker is using containerd
• Apple Virtualization framework (not QEMU, as the error seems to suggest) with Rosetta
  • Prior to a full purge/reinstallation of Docker Desktop, I was using Docker VMM. Same issue.

Relevant log output

[7007 ms] Resolving Feature dependencies for 'ghcr.io/devcontainers-extra/features/heroku-cli:1'...
[7007 ms] * Processing feature: ghcr.io/devcontainers-extra/features/heroku-cli:1
[7190 ms] Soft-dependency 'ghcr.io/devcontainers/features/git' is not required.  Removing from installation order...
[7190 ms] Soft-dependency 'ghcr.io/devcontainers/features/git' is not required.  Removing from installation order...
[7190 ms] * Fetching feature: heroku-cli_0_oci
[7742 ms] Files to omit: ''
[7743 ms] * Fetched feature: heroku-cli_0_oci version 1.0.4
[7743 ms] * Fetching feature: common-utils_1_oci
[8254 ms] Files to omit: ''

[koralowiec]

Hi!

I was able to replicate your issue on M1 Macbook with the following devcontainer.json:

{
	"name": "Ruby",
	"image": "mcr.microsoft.com/devcontainers/ruby:1-3.4-bullseye",
	"features": {
		"ghcr.io/devcontainers-extra/features/heroku-cli:1": {}
	}
}

I'm not sure what's exactly causing the issue, I would need to investigate it more deeply.

However, I was able to find a workaround.

It's possible to declare the target platform with --platform flag in Dockerfile, so I used linux/amd64 in .devcontainer/Dockerfile:

FROM --platform=linux/amd64 mcr.microsoft.com/devcontainers/ruby:1-3.4-bullseye

And updated .devcontainer/devcontainer.json:

{
	"name": "Ruby",
	"build": {
		"dockerfile": "./Dockerfile"
	},
	"features": {
		"ghcr.io/devcontainers-extra/features/heroku-cli:1": {}
	}
}

Result after rebuilding the Dev Container:

My Docker Desktop Virtual Machine Options:

[rhysb27]

Hi @koralowiec, thanks for helping out! I seemed to have some progress with the platform flag but the result was dreadfully slow compared to what I'm used to. Is that normal?

If for now it's a choice between that and the contra-advised npm installation method then I'm going to have to choose the latter.

[koralowiec]

To be honest, I don't know if it should be slow, worked kinda fine for me, but I only run a single command in the devcontainer

For now, i don't have any proper fix (as I wasn't able to sit and debug it), or a better workaround

[zachmullen]

Switching your whole container to amd64 isn't actually a fix, it's a (kind of bad) workaround -- you're now having to do ISA emulation for your whole container, which will massively slow it down. Furthermore, x86 emulation support is slated to be dropped from MacOS in ~2027.

I believe the faulty logic is here:

features/src/heroku-cli/install.sh

Lines 23 to 24 in da114ee

	elif [[ "$ARCH" == aarch* ]]; then
	ARCH=arm

That's using a platform name regex match to assume that you're on a 32-bit ARM CPU, but you're actually on a 64-bit one. On my 64-bit M4 mac, inside the container, here is the output of the relevant command:

$ uname -m
aarch64

Note that it will match the aarch* expression and assume 32-bit. One simple fix would be to add a specific check for aarch64 prior to the 32-bit fallback check.

[koralowiec]

New feature version should be available once this release job is done