supabase / auth / 29354833746
72%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 196
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: 71.718% (-0.01%) from 71.729%
29354833746

push

github

web-flow 
fix: build darwin-arm64 release binaries with GOOS=darwin (#2618)

## What

Every `auth-v*-darwin-arm64.tar.gz` release asset since `rc2.189.0-rc.1`
contains a **Linux ELF binary** under the darwin name, so it can never
execute on macOS:

```
$ file auth   # from auth-v2.192.0-darwin-arm64.tar.gz
auth: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked
```

The cause is one token in the Makefile — the `auth-darwin-arm64` recipe
sets `GOOS=linux`, a copy-paste of the `auth-arm64` recipe above it:

```makefile
auth-darwin-arm64: deps
	CGO_ENABLED=0 GOOS=linux GOARCH=arm64 $(call BUILD_CMD,$(@),)
```

This PR changes it to `GOOS=darwin` and adds a `verify-release` target
so a name/content divergence fails the release instead of shipping.

## Timeline

- #2400 introduced the darwin-arm64 build **correctly** (`GOOS=darwin`,
merged 2026-03-02); v2.188.0/v2.188.1 shipped genuine Mach-O binaries.
- #2436 restructured the inline release builds into per-target rules for
parallelization (merged 2026-03-25); the new `auth-darwin-arm64` rule
was written with `GOOS=linux`.
- Every release from `rc2.189.0-rc.1` onward ships the mislabeled binary
— verified with `file(1)` against `v2.188.1` (Mach-O, the pre-regression
control), `v2.189.0`, `v2.191.0`, `v2.192.0`, `v2.192.1-rc.2`, and
`v2.193.0-rc.3` (all ELF).

## Why nothing caught it

The archive **name** comes from the make target stem, while the archive
**content** comes from the recipe's env vars — nothing checks that they
agree. The release-notes checksums are computed over the same wrong
binary, so checksum verification can't catch it either. Downstream, the
consumer this asset appears to have been added for (the local stack's
native mode in supabase/cli) restart-loops the un-executable binary with
no diagnostic, so the failure never surfaced as a report.

The new `verify-release` target closes that structural gap. It hooks
into the existing `release` target, so it runs inside the curr... (continued)

18080 of 25210 relevant lines covered (71.72%)

663.44 hits per line

Coverage Regressions

Lines Coverage ∆ File
3
59.47
 -0.62% internal/api/oauthserver/handlers.go
Jobs
ID Job ID Ran Files Coverage
1 29354833746.1 196
71.72
 GitHub Action Run
Source Files on build 29354833746