Compare commits

...
Author SHA1 Message Date
ops-ci-01 09b7c369c5 Merge remote-tracking branch 'origin/next' into ci/push-ci-comment-model
ci/woodpecker/pr/ci Pipeline was successful
2026-08-19 19:14:40 -05:00
ops-ci-01 ce633b4d50 docs(ci): correct the merge-ref claim; PR CI tests the head tree
My own comment asserted 'PR CI tests the merge ref, whose tree equals the
landed squash commit' - never measured. Pipeline API refs show pull_request
runs execute refs/pull/N/head (2542, 2545): the head tree, not a merge ref.
If next advances between run and merge, the landed tree differs from the
tested one; that residual is what publish verify re-covers post-merge (full
verify:release on the push, PGlite path). Same evidence discipline this PR
exists to enforce; the claim is corrected to what was measured.
2026-08-19 19:14:40 -05:00
ops-ci-01 cb9a0d1642 ci: pin ci-base to immutable lock-9cb7ffcd8828 (Closes #1328) (#1329)
ci/woodpecker/push/publish Pipeline was successful
Co-authored-by: ops-ci-01 <[email protected]>
2026-08-19 23:42:05 +00:00
ops-ci-01 781a1fddc5 docs(ci): soften protection parenthetical to the measurable claim
ci/woodpecker/pr/ci Pipeline failed
rev-code-01 review id 215: the branch-protection API is admin-gated for seat
tokens, so 'required status check' cannot be evidenced inline; the comment
states only what carries its own evidence. Protection and default-branch
status are API-readable and stay.
2026-08-19 18:41:48 -05:00
ops-ci-01 bdf9f68175 docs(ci): state the measured push-CI model in ci.yml's when-comment
ci/woodpecker/pr/ci Pipeline was successful
The old comment said push CI is restricted to "protected branches (main)",
which implied next lacked post-merge verification. next is protected and the
default branch since 2026-08-19, and it is not unverified: publish.yml's
verify step runs the complete mandatory set on every push to next, mirroring
this pipeline step-for-step (enforced by verify-release.test.mjs). The
postgres run and push-ci status context it does not re-run duplicate
pre-merge coverage, since PR CI tests the merge ref whose tree equals the
squash commit. Measured 2026-08-19: the 21 most recent push events on next
each ran exactly one pipeline (publish), zero ci. No behavior change.
2026-08-19 17:45:24 -05:00
2 changed files with 34 additions and 7 deletions
+28 -6
View File
@@ -2,16 +2,38 @@
# node:24-alpine + python3/make/g++/postgresql-client + pnpm + a warm pnpm
# store. The install step resolves from the baked store (--prefer-offline)
# instead of paying a ~731s cold fetch + native compile every run.
#
# PINNED to an immutable lock-tag (#1328, brain D27): ci-image.yml pushes
# lock-<sha256(pnpm-lock.yaml)[:12]> atomically with :latest, so the two are
# byte-identical at push time. A mutable :latest resolves per-pod at pull time
# on the k8s backend, which made CI verdicts non-reproducible (same tree, same
# config, different images across runs; see #1324 comment 23382/23386). The pin
# changes ONLY through reviewed commits; a wrong tag fails loudly at image pull.
#
# Bump procedure: when a recipe change (pnpm-lock.yaml / Dockerfile.ci) lands on
# main, ci-image.yml pushes lock-<new>; a follow-up PR updates this anchor.
# Until then pipelines keep the old pin: reproducible, with the documented
# network-fallback lag (frozen-lockfile resolves missing packages from network).
# Known limitation: lock- addresses the lockfile only, so a Dockerfile-only
# change re-pushes the same tag with new content (#1328 follow-up: recipe-hash).
variables:
- &node_image 'git.mosaicstack.dev/mosaicstack/stack/ci-base:latest'
- &node_image 'git.mosaicstack.dev/mosaicstack/stack/ci-base:lock-9cb7ffcd8828'
- &enable_pnpm 'corepack enable'
when:
# PR + manual CI run on any branch the pull_request pipeline is the merge gate.
# push CI is restricted to protected branches (main) so a feature-branch push no
# longer fires a redundant SECOND pipeline alongside its PR pipeline. This ~halves
# CI load on the storage-constrained runner with zero loss of gating (branch
# protection requires no push/ci status context; main still gets full push CI).
# PR + manual CI run on any branch: the pull_request pipeline is the merge
# gate (next is protected and the default branch since 2026-08-19).
# Push CI runs on main only. next deliberately runs NO push ci: post-merge
# verification on next is carried by publish.yml's `verify` step
# (pnpm verify:release), which mirrors this pipeline's complete mandatory
# set step-for-step, enforced by scripts/verify-release.test.mjs. PR CI
# tests the PR HEAD tree (refs/pull/N/head, measured 2026-08-19), not a
# merge ref, so if next advances before a merge the landed tree differs
# from the tested one; publish verify re-runs the full set on the landed
# tree (PGlite path). Measured 2026-08-19: the 21 most recent push events
# on next each ran exactly one pipeline (publish), zero ci.
# Keeping push ci off next also avoids a redundant second full-suite run
# per merge on the storage-constrained runner.
- event: [pull_request, manual]
- event: push
branch: main
+6 -1
View File
@@ -18,7 +18,12 @@
variables:
# Pre-baked CI base (see .woodpecker/ci-image.yml): node:24-alpine +
# toolchain + warm pnpm store. Kills the second cold install publish pays.
- &node_image 'git.mosaicstack.dev/mosaicstack/stack/ci-base:latest'
# PINNED to the immutable lock-tag, not :latest (#1328, brain D27): a mutable
# tag resolves per-pod at pull time on the k8s backend and made CI verdicts
# non-reproducible (#1324). Byte-identical to :latest at pin time (pushed
# atomically by the same kaniko run, main 712c770, 2026-07-26). Bump only via
# reviewed PR, per the procedure in .woodpecker/ci.yml's header comment.
- &node_image 'git.mosaicstack.dev/mosaicstack/stack/ci-base:lock-9cb7ffcd8828'
- &enable_pnpm 'corepack enable'
# Heavy kaniko image builds (~25 min) — gate them so a merge that only touches
# the npm-only CLI (@mosaicstack/mosaic) or docs does NOT rebuild the platform