mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-09 13:01:00 +00:00
Marc-André BombeckandClaude Opus 4.7
249c42bdd2
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) <noreply@anthropic.com>
106 lines
4.1 KiB
YAML
106 lines
4.1 KiB
YAML
name: Build & Publish Docker Image
|
|
|
|
on:
|
|
push:
|
|
branches: [main]
|
|
tags: ["v*"]
|
|
pull_request:
|
|
branches: [main]
|
|
workflow_dispatch:
|
|
|
|
env:
|
|
REGISTRY: ghcr.io
|
|
IMAGE_NAME: ${{ github.repository }}
|
|
|
|
# Cancel in-progress runs when a new commit is pushed to the same ref.
|
|
concurrency:
|
|
group: docker-publish-${{ github.ref }}
|
|
cancel-in-progress: true
|
|
|
|
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
|
|
|
|
steps:
|
|
- name: Checkout
|
|
uses: actions/checkout@v4
|
|
|
|
- name: Set up QEMU (multi-arch)
|
|
uses: docker/setup-qemu-action@v3
|
|
|
|
- name: Set up Docker Buildx
|
|
uses: docker/setup-buildx-action@v3
|
|
|
|
# Skip login on PRs from forks — they don't have package:write.
|
|
# Image is built but not pushed in that case.
|
|
- name: Log in to GitHub Container Registry
|
|
if: github.event_name != 'pull_request'
|
|
uses: docker/login-action@v3
|
|
with:
|
|
registry: ${{ env.REGISTRY }}
|
|
username: ${{ github.actor }}
|
|
password: ${{ secrets.GITHUB_TOKEN }}
|
|
|
|
- name: Compute image tags & labels
|
|
id: meta
|
|
uses: docker/metadata-action@v5
|
|
with:
|
|
images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
|
|
tags: |
|
|
type=ref,event=branch
|
|
type=ref,event=pr
|
|
type=semver,pattern={{version}}
|
|
type=semver,pattern={{major}}.{{minor}}
|
|
type=raw,value=latest,enable={{is_default_branch}}
|
|
type=sha,prefix=sha-,format=short
|
|
labels: |
|
|
org.opencontainers.image.title=HealthLog
|
|
org.opencontainers.image.description=Self-hosted health-tracking PWA
|
|
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:
|
|
context: .
|
|
file: ./Dockerfile
|
|
platforms: linux/amd64,linux/arm64
|
|
push: ${{ github.event_name != 'pull_request' }}
|
|
tags: ${{ steps.meta.outputs.tags }}
|
|
labels: ${{ steps.meta.outputs.labels }}
|
|
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
|