supabase / cli / 27876449826
65%
develop: 65%

LAST BUILD BRANCH: gh-readonly-queue/develop/pr-5642-893960a6e9fae412eb0215afae05f1348e356e62
DEFAULT BRANCH: develop
Ran
Jobs 1
Files 227
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 64.939% (+0.02%) from 64.921%
27876449826

push

github

web-flow 
ci(release): mount binfmt_misc on the host for arm64 smoke tests on cold runners (#5641)

## What changed

In the `smoke-test` job of `release-shared.yml`, mount the host's
`binfmt_misc` before installing QEMU:

```sh
mountpoint -q /proc/sys/fs/binfmt_misc || {
  sudo modprobe binfmt_misc || true
  sudo mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc
}
```

The step runs **after** the containerd-snapshotter Docker restart (so
nothing disturbs the mount), then QEMU is installed, then an assertion
confirms the `qemu-aarch64` handler landed in the host kernel.

## Root cause

The arm64 Linux package smoke tests (`docker run --platform linux/arm64
…`) were failing with `exec /bin/sh: exec format error`.

On cold/fresh Blacksmith VMs the host's `/proc/sys/fs/binfmt_misc` is
**not mounted**. The privileged `tonistiigi/binfmt` installer that
`setup-qemu-action` runs then registers the qemu interpreters inside its
**own mount namespace** — it prints `installing: arm64 OK`, but the
handlers vanish when the container exits, so the host kernel never gains
arm64 emulation. Warm/reused VMs already had `binfmt_misc` mounted from
a prior job, which is why this failed only intermittently — perfectly
correlated with a `smoke-docker-images-…` cache miss (a proxy for a cold
VM).

It is not a code regression: there were 19 green release runs through
2026-06-19, and the only commit between the last green and the first red
run was an unrelated `supabase/postgres` bump. The trigger was simply
landing on a cold VM.

> Note: the earlier fix (#5639), which reordered QEMU before the
containerd restart, was based on the wrong theory and did not fix it —
the next release on a cold runner still failed. The assertion added in
#5639 is what surfaced the true cause (handler absent on the host
immediately after install, before any restart).

## How this was tested

Validated on a real `blacksmith-8vcpu-ubuntu-2404` runner with a
temporary diagnostic workflow (since removed f... (continued)

10752 of 16557 relevant lines covered (64.94%)

7.37 hits per line

Jobs
ID Job ID Ran Files Coverage
1 27876449826.1 227
64.94
 GitHub Action Run
Source Files on build 27876449826