bvandeusenandClaude Opus 5
22a9a279b1
Android / Build, or is the channel already serving this? (push) Successful in 3s
CI & Build / Python lint (push) Successful in 3s
CI & Build / Build now, or wait for Android? (push) Successful in 3s
Desktop (Tauri) / Build, or is the channel already serving this? (push) Successful in 3s
CI & Build / TypeScript typecheck (push) Successful in 7s
CI & Build / Python tests (push) Successful in 10s
CI & Build / integration (push) Successful in 16s
CI & Build / Build & push image (push) Skipped
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 3m5s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 5m24s
Desktop (Tauri) / Update manifest (push) Successful in 4s
Android / Kotlin + Rust (APK) (push) Successful in 8m12s
Step 6 of M314. Two changes that only make sense together.
## The image tag set rule 145 mandates
dev push -> :dev
main push -> :latest + :<sha>
a v* tag -> nothing; the trigger is gone
`:<sha>` was going out on EVERY branch — a rollback target nobody has ever
pulled, accumulating forever, for a channel whose entire contract is that it
moves. It is on main only now, where rollback matters and where gated merges
(rule 2) make it dozens per year rather than one per push.
No version-shaped image tag in any lane. Verified the way rule 145 asks — by
looking for a CONSUMER, not for whether one is imaginable: `docker-compose.yml`
is parameterised for a pin and the docs describe the option, but no compose
file, deploy script or CI job reads one.
## Skip-if-exists, adapted, because §4 assumes a registry §5 removed
Note 3127 §4 says to ask the registry whether that exact version exists. There
is no `:<version>` tag to ask about any more. What there IS, for both clients,
is a channel that publishes the version it serves — and that answers the same
question: if the channel already serves what this source derives, the artifact
would be byte-identical.
So the `paths:` filters are gone from the desktop and Android lanes, replaced
by a `decide` job reading the real file set. That duplication is not
theoretical: `packaging/` was added to the sets and not to the filters, so the
commit that fixed a derivation bug never ran on the two lanes it fixed
(85ead4d). One definition, one reader.
The cost is that both workflows now start on every push rather than a matching
one — a ~15s container for a decision, against a lane that cannot silently fail
to run.
## The server always builds, deliberately
Its image is ~15 seconds against 6 and 9 minutes for the clients, so there is
little to save. And always building is strictly BETTER for something that can
face the internet: it picks up `python:3.12-slim` base updates on every push.
That also dissolves §4's base-image tension for this project rather than
deciding it — the artifact most exposed to base staleness is the one that never
skips. Resolving a base digest at derive time was the alternative and it is
forbidden: §7's corollary bars an external lookup, because two lanes would then
derive different values for one source.
## The guard runs on the skip path
It moved into `decide`, ahead of the decision. §6.3 is explicit that skipping
because "this version already exists" is indistinguishable from "we derived a
stale value that happens to match" unless something checks. It also now runs
once per lane instead of once per job.
## Two defects found while wiring this
`ci.yml`'s gate greps a path list that MUST match Android's file set, and
`packaging/` was missing from it. A packaging-only push would have had the
Android lane build and dispatch while the gate ALSO let the image through —
two images for one commit, and on main a second push of the same `:<sha>` with
different bytes. Rule 145's exact prohibition.
`guard-forward.sh` ends every fetch in `|| true`, so a runner image without
curl would have read as "nothing published yet" and passed without checking
anything. Missing curl is now fatal.
#3146
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
77 lines
3.4 KiB
Bash
Executable File
77 lines
3.4 KiB
Bash
Executable File
#!/usr/bin/env sh
|
|
#
|
|
# Does this artifact need building, or is the channel already serving this exact
|
|
# source? Prints `true` or `false`.
|
|
#
|
|
# should-build.sh <desktop|android> <dev|stable>
|
|
#
|
|
# Note 3127 §4, skip-if-exists — adapted, because §4 assumes a registry keyed by
|
|
# VERSION and rule 145 removed exactly that. There is no `:<version>` tag to ask
|
|
# about. What there IS, for both clients, is a channel that publishes the version it
|
|
# is serving, and that answers the same question: if the channel already serves what
|
|
# this source derives, the artifact would be byte-identical and there is nothing to
|
|
# build.
|
|
#
|
|
# WHAT THIS REPLACES, and why that matters more here than the cost saving: the
|
|
# `paths:` filters in the workflows were a SECOND, independent statement of each
|
|
# artifact's file set, hand-kept beside the one in `version.sh`. They disagreed
|
|
# within a day of the sets being written — `packaging/` was added to the sets and
|
|
# not to the filters, so the commit that fixed a derivation bug never ran on the two
|
|
# lanes it fixed (85ead4d). §3 warns about exactly this duplication; one definition
|
|
# with one reader is the fix, and the cost saving is a bonus.
|
|
#
|
|
# THE SERVER IS NOT LISTED HERE, DELIBERATELY. Its image build is ~15 seconds against
|
|
# 6 and 9 minutes for the clients, so there is little to save — and always building
|
|
# it is strictly better for a server that can face the internet, because it picks up
|
|
# `python:3.12-slim` base updates on every push. That is also why the base-image
|
|
# tension in §4 does not bite this project: the artifact most exposed to it never
|
|
# skips. The clients' bases are CI runner images, pinned deliberately.
|
|
set -eu
|
|
|
|
ROOT="$(cd "$(dirname "$0")/.." && pwd)"
|
|
|
|
artifact="${1:?usage: should-build.sh <desktop|android> <dev|stable>}"
|
|
channel="${2:?usage: should-build.sh <desktop|android> <dev|stable>}"
|
|
|
|
case "$artifact" in desktop|android) : ;; *)
|
|
echo "should-build.sh: unknown artifact '$artifact'" >&2; exit 2 ;;
|
|
esac
|
|
case "$channel" in dev|stable) : ;; *)
|
|
echo "should-build.sh: unknown channel '$channel'" >&2; exit 2 ;;
|
|
esac
|
|
|
|
# The value that answers "is this the same code?" — which is not the same as the one
|
|
# the guard compares.
|
|
#
|
|
# desktop the ordering key IS the identity; one value, one clock.
|
|
# android the NAME. Its versionCode is build-time and moves every run, so
|
|
# comparing that would report a change on every push and never skip.
|
|
case "$artifact" in
|
|
desktop) derived="$(sh "$ROOT/packaging/version.sh" key desktop)" ;;
|
|
android) derived="$(sh "$ROOT/packaging/version.sh" display android)" ;;
|
|
esac
|
|
|
|
published="$(sh "$ROOT/packaging/guard-forward.sh" published "$artifact" "$channel")"
|
|
|
|
if [ -z "$published" ]; then
|
|
echo "should-build: $channel serves no $artifact yet — building." >&2
|
|
echo true
|
|
exit 0
|
|
fi
|
|
|
|
if [ "$derived" = "$published" ]; then
|
|
# UNCHANGED. The channel is already serving this exact source, so a build would
|
|
# produce the same artifact under the same name and republish it for nothing.
|
|
#
|
|
# Skipping is safe here in a way it would not be if anything pinned: there is no
|
|
# immutable tag to re-push with different bytes (rule 145 removed version tags),
|
|
# so the immutability argument in §4.2 does not apply and this stands on cost
|
|
# alone — which is the smaller, honest claim.
|
|
echo "should-build: $channel already serves $artifact $derived — skipping." >&2
|
|
echo false
|
|
exit 0
|
|
fi
|
|
|
|
echo "should-build: $artifact moved $published -> $derived — building." >&2
|
|
echo true
|