Skip to content

ci: do not fail-fast the release build matrix - #42

Open
oc-tmueller wants to merge 1 commit into
masterfrom
ci/no-fail-fast-release-matrix
Open

ci: do not fail-fast the release build matrix#42
oc-tmueller wants to merge 1 commit into
masterfrom
ci/no-fail-fast-release-matrix

Conversation

@oc-tmueller

Copy link
Copy Markdown
Member

What

Adds fail-fast: false to the release build matrix in .github/workflows/main.yml.

Why

Each release line is built and Trivy-scanned against its own oCIS binary, so a finding on one
line says nothing about the others. With fail-fast at its default (true), the first failing
leg cancels the remaining ones mid-Build image, and their real status is never reported.

This is not hypothetical. The 8.1.0 leg has been failing its Trivy gate since 2026-09-02,
which has cancelled the 8.2.0 and 8.0.8 legs in every run since — including
run 34207664511, an unrelated
Renovate docker.io/golang bump.

While investigating that failure it turned out the 8.2.0 line is affected by exactly the same
three advisories, which had gone unnoticed for a week purely because its leg never reached the
scan:

Advisory Dependency v8.2.0 pins Fixed in
CVE-2026-56854 (CRITICAL) golang.org/x/crypto v0.54.0 0.55.0
CVE-2026-46603 (HIGH) golang.org/x/image v0.44.0 0.45.0
CVE-2026-84304 (HIGH) google.golang.org/grpc v1.82.1 1.83.1

8.2.0 carries the latest tag, so that is the leg whose status we can least afford to have
masked.

Expected result on this PR

This change does not make CI green — it makes it truthful. On this PR expect:

  • 8.1.0 — still fails, same three advisories (unchanged behaviour)
  • 8.2.0 — now reaches its Trivy step and is expected to fail with the same three
  • 8.0.8 — now reaches its Trivy step and is expected to pass (v8.0.8 ships x/crypto v0.55.0,
    x/image v0.45.0, grpc v1.83.1)

No .trivyignore entries are added here. The fixes belong upstream and are tracked as
owncloud/ocis#12903 (8.2 — needs a grpc v1.83.0 → v1.83.1 bump on stable-8.2 plus an 8.2.1
release) and owncloud/ocis#12810 (8.1 — stable-8.1 is already clean, just never tagged).

🤖 Generated with Claude Code

Each release line is built and Trivy-scanned against its own oCIS binary, so a
finding on one line says nothing about the others. With fail-fast at its default,
the first failing leg cancels the remaining ones mid-build and their real status
is never reported.

This is not hypothetical: the 8.1.0 leg has been failing its Trivy gate since
2026-09-02, which cancelled the 8.2.0 and 8.0.8 legs in every run since. The
8.2.0 line turns out to be affected by the same three advisories (its go.mod
pins golang.org/x/crypto v0.54.0, golang.org/x/image v0.44.0 and
google.golang.org/grpc v1.82.1), and that went unnoticed for a week purely
because the leg never reached its scan. Tracked upstream as owncloud/ocis#12903
for 8.2 and owncloud/ocis#12810 for 8.1.

This does not make CI green -- it makes it truthful.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@oc-tmueller

Copy link
Copy Markdown
Member Author

CI result on this PR confirms the intent — all three release lines reached their Trivy step
instead of being cancelled (run 34209989065):

Line Result Findings
8.0.8 ✅ pass (both arches) none
8.1.0 ❌ fail CVE-2026-56854, CVE-2026-46603, CVE-2026-84304
8.2.0 ❌ fail CVE-2026-56854, CVE-2026-46603, CVE-2026-84304

The 8.2.0 scan matched the go.mod-derived prediction exactly (x/crypto v0.54.0, x/image v0.44.0,
grpc v1.82.1) — posted in full on owncloud/ocis#12903. That finding is the whole reason for this
PR: without it, the 8.2 line's exposure stays hidden behind the 8.1 failure.

One residual limitation worth flagging: the per-line legs are now independent, but the two
architecture legs within a line still cancel each other, because the inner matrix in
owncloud-docker/ubuntu's docker-build-native.yml
also has no fail-fast: false. In this run that showed up as e.g. 8.2.0/arm64 failing and
8.2.0/amd64 being cancelled. That is harmless for the case this PR addresses — each line still
reports its own verdict, and both arches of a line build the same dependency set — so I have left
it alone rather than widen the change into another repo. Happy to follow up there if you would
prefer full independence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant