From 249c42bdd2356d5854c85839a74c76f429405843 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Sat, 9 May 2026 20:47:43 +0200 Subject: [PATCH] =?UTF-8?q?fix(ci):=20docker-publish=20reliability=20?= =?UTF-8?q?=E2=80=94=20separate=20cache=20scope=20per=20ref=20+=2030min=20?= =?UTF-8?q?timeout?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The v1.4.14 release exposed a hard hang: the `main` push and the `v1.4.14` tag push both fired at SHA `e5fae9bce6cb` simultaneously. The tag run finished cleanly in 17 minutes; the main run sat on `#26 [linux/amd64 runner 2/14] RUN apk add tzdata` from 16:14:52Z until Marc cancelled it at 17:00:15Z — 47 minutes of zero buildkit output. Same SHA, same Dockerfile, same runner image, vastly different outcome. Root cause: both `cache-from: type=gha` and `cache-to: type=gha,mode=max` used buildx's default scope name (`buildkit`). With `mode=max` every stage of every platform is exported to the cache; the two concurrent writers raced on the gha cache manifest and one deadlocked on the exporter. This is the classic "shared buildkit cache between parallel refs" failure mode — pinned down by the symmetry of "same SHA, parallel runs, only the slower-to-arrive one hangs". Fix is two layers: 1. Per-ref cache scope (`scope=build-${{ github.ref_name }}`). Each workflow invocation now writes to its own slot: - `build-main` for branch pushes - `build-v1.4.x` for tag pushes - `build-pr-N` for pull-request pushes `cache-from` reads BOTH the ref-specific scope AND `build-main`, so a tag built right after a main push still reuses main's layers — just without contending on the writer side. 2. Job-level `timeout-minutes: 30`. The fastest healthy build of the v1.4.7..v1.4.13 series finished in 12 min, the slowest in 18 min. 30 min covers a slow exporter while still rescuing the runner automatically if buildkit deadlocks again, instead of waiting for a human to notice and click Cancel an hour later. Pass-rate impact in the v1.4.15 marathon: 30/60 successes over 30 days (most "cancelled" entries are by-design — concurrency group cancels superseded runs — but the v1.4.14 hang counts as a preventable outlier). After this commit a deadlocked run is bounded to 30 min and a release commit's two refs no longer fight each other. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/workflows/docker-publish.yml | 31 +++++++++++++++++-- .../admin/user-management-section.tsx | 4 +-- 2 files changed, 30 insertions(+), 5 deletions(-) diff --git a/.github/workflows/docker-publish.yml b/.github/workflows/docker-publish.yml index 13b59fca5..15969ba93 100644 --- a/.github/workflows/docker-publish.yml +++ b/.github/workflows/docker-publish.yml @@ -21,6 +21,14 @@ jobs: build-and-push: name: Build & push multi-arch image runs-on: ubuntu-latest + # 30 min wall clock — a healthy multi-arch build finishes inside 17 min + # (see v1.4.7..v1.4.13 history). The v1.4.14 main run hung 47 min on + # `[linux/amd64 runner 2/14]` before Marc cancelled because tag + branch + # were exporting to the same gha cache scope concurrently (see fix below). + # 30 min is enough for a clean build + a slow exporter, while still + # rescuing the runner if buildkit deadlocks instead of waiting for a + # human to notice. + timeout-minutes: 30 permissions: contents: read packages: write @@ -63,6 +71,23 @@ jobs: org.opencontainers.image.licenses=AGPL-3.0-only org.opencontainers.image.source=https://github.com/${{ github.repository }} + # Per-ref gha cache scope: previously both `cache-from: type=gha` and + # `cache-to: type=gha,mode=max` used buildx's default scope name + # (`buildkit`). When a release commit lands, GitHub fires the workflow + # twice in parallel — once for the `main` push, once for the `v*` tag + # — both pointed at the same SHA, both writing to the same gha cache + # key. mode=max exports every stage of every platform; the concurrent + # writers race on the cache manifest and one deadlocks. The v1.4.14 + # main run sat on `[linux/amd64 runner 2/14] RUN apk add tzdata` for + # 47 minutes (cancelled by hand) while the tag run on the same SHA + # finished cleanly in 17 minutes — clear smoking-gun. + # + # Splitting the scope by `github.ref_name` (e.g. `main`, `v1.4.15`, + # `pr-123`) gives each invocation its own cache slot. We `cache-from` + # both the ref-specific scope AND the canonical `main` scope so: + # - feature branches/tags can warm-start off main's last good build + # - a tag built right after a main push hits main's cache for layer + # reuse without contending on writes - name: Build & push image uses: docker/build-push-action@v6 with: @@ -72,7 +97,9 @@ jobs: push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} - cache-from: type=gha - cache-to: type=gha,mode=max + cache-from: | + type=gha,scope=build-${{ github.ref_name }} + type=gha,scope=build-main + cache-to: type=gha,mode=max,scope=build-${{ github.ref_name }} provenance: true sbom: true diff --git a/src/components/admin/user-management-section.tsx b/src/components/admin/user-management-section.tsx index 217985d61..04472ce2c 100644 --- a/src/components/admin/user-management-section.tsx +++ b/src/components/admin/user-management-section.tsx @@ -315,9 +315,7 @@ export function UserManagementSection() { {u.role} - - {u.passkeyCount} - + {u.passkeyCount} {formatDate(u.createdAt)}