6 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	270ad7a71b	fix(ci): tests do not ship, so they must not re-version an artifact ... Completes the pathspec. 17212e9e excluded CI, docs and tooling but left tests in the shipped set, so its own commit re-versioned the image on the strength of a _test.go file. `go build` drops *_test.go outright and the Vite build never imports a .test.ts — neither reaches an image or an APK. Globs over files rather than a directory exclusion, because this repo has no tests/ tree to exclude: Go tests sit inline beside the code they cover (158 files) and the web suite beside its modules (115). Patterns match what exists and nothing speculative — there are no .spec.* files, no __tests__/ directories and no androidTest/ tree. If any appear they re-version until named, which is the harmless direction and the point of a denylist. The guard that matters is not "a test-only commit is inert" — it is that a commit touching a test AND its source still moves the version. `':!internal'` would satisfy every inertness assertion while silently excluding the entire server, which is the stale-version-on-changed-artifact failure this whole derivation exists to prevent. Falsified: drop the Go exclusion and a _test.go commit moves the version; drop the web one and a .test.ts does; replace the globs with `':!internal'` and the source-alongside-test case breaks. That last check failed first time, on a bug in the FIXTURE rather than the derivation, and it is worth recording because it makes a test pass for the wrong reason. Both commit helpers wrote the constant "x\n", so re-writing a file with identical bytes recorded NOTHING — the "source and test together" commit actually contained only the test, and the assertion was quietly checking the case it was meant to contrast against. Content is now derived from the commit's epoch, and the test asserts HEAD really contains both paths before drawing any conclusion from it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 18:21:12 -04:00
bvandeusenandClaude Opus 5	17212e9eb4	fix(ci): version derives from the shipped set; untrack an 18MB binary ... Three build-hygiene fixes that turned up while explaining the pathspec. **version.sh derives from what SHIPPED.** It read bare HEAD, so any commit moved the version — including one touching only CI or a README. Rules 148 and 149 both specify the pathspec form. Now a denylist, and the direction is the point: as an allowlist the list must be updated by whoever adds a directory and nothing fails if they don't, so the failure mode is a changed artifact keeping its old version silently on a green run. Inverted, new content counts by default. android/ is deliberately NOT excluded, and that is the subtle part. This repo ships TWO artifacts from ONE derivation: android/ is in no server image, but it is the APK's entire source, and excluding it would stop an Android-only commit from moving the APK's own version — the silent downgrade the versioning rework exists to prevent. So the list is the union: exclude only what ships in neither, and accept that an Android commit also nudges the server's reported version. Over-inclusion across the two, which is the harmless direction. roundtable/roundtable-android each keep tighter lists because they are one-artifact repos; don't copy theirs. **.dockerignore excluded the wrong CI directory.** It named .forgejo/ and .github/, neither of which this repo has. Gitea Actions reads .gitea/, so the one directory that exists was the one not excluded. The "Flutter mobile client" block had also lost its PATTERN when flutter_client/ was deleted, leaving a comment describing an exclusion that was not happening — android/ never took its place, so 4.1MB of Gradle project entered the context and busted the `COPY . .` layer on every Android-only change. bin/ excluded too. **bin/minstrel was tracked** — an 18MB binary last refreshed by a commit about web test mocks, and re-dirtied by every `make build` since. Untracked and ignored; the file stays on disk. Guards are behavioural rather than textual: they build throwaway repos with pinned commit timestamps and run version.sh against them, so they break when the derivation changes rather than when the wording does. Falsified — drop the .gitea exclusion and the CI-only commit moves the version; add an android exclusion and an Android commit stops moving it; exclude everything and a source commit refuses. One honest note on the refusal test: the script already refused an empty result via the downstream date check, so the new explicit check improves the diagnostic ("no commit touches the shipped file set — shallow clone?") and not the safety. The test pins the property, which is defended in depth. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 17:55:36 -04:00
bvandeusenandClaude Opus 5	aeb8781c4e	fix(release): drop version image tags, mint the rollback unit on main ... The image tag map was the inverse of family rules 145 and 147 on every count: it published :vYYYY.MM.DD.HHMM that nobody pinned, published :main that rule 147 says should not exist, and published no commit-addressable image at all — so the rollback unit the rule names did not exist in this repo. A bad main push had nothing to roll back to but the previous release tag, which may be many commits back. The whole map is now: dev → :dev main → :latest + :<sha> tag → :latest A release refreshes the channel and mints nothing else. The tag build rebuilds the SAME SOURCE as main's build minutes earlier, differing only in which APK is baked in, so rule 145's immutability clause applies directly: move the channel tag, never re-push a commit-addressable one. :latest has to move here rather than waiting for the next main push, or the channel would carry the previous release's APK indefinitely — a channel that cannot refresh itself (rule 146). Two consequences that are not optional: The verify job asserted the :<version> image existed. With version tags gone that would fail every release for a tag nothing mints. Re-pointed at the :<sha> image rather than deleted — deleting it is the tempting way to make a failing guard go green, and it earns its keep twice now: it still catches an image push that silently did not happen, and it additionally proves the ordering, since a tag cut on a commit whose main build never completed has no rollback target. The server's self-reported version was the literal string "main" or "dev". That was survivable while :vYYYY.MM.DD.HHMM existed to identify a build; with version tags gone it is the ONLY thing that says which build is running, and two dev images months apart were indistinguishable. It now carries the derived name from ci/version.sh on every lane, with the channel as a sibling field (rule 149) rather than folded into the string. Surfaced at /healthz and beside the version in Settings. Guards added for each arm of the policy, and every one was falsified against the specific regression it names before committing. That caught two real bugs in the guards themselves: stepBody cut at the next `- name:`, which returns an EMPTY body for the last step in a job and made the assertions pass vacuously, and its replacement cut at any blank line followed by indentation, which truncated a step mid-run-block. The helper now refuses an empty body outright. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 15:10:15 -04:00
bvandeusenandClaude Opus 5	88508b536b	fix(release): a non-matching grep must not kill the rebundle step ... The first `main` build after the version rework failed, and the bug was mine. :latest was never moved — "Build and push" was skipped — so nothing reached production, but every subsequent main push would have failed the same way. The runner invokes `shell: bash` as `bash -e -o pipefail`. Under pipefail a command substitution reports the FIRST non-zero status in its pipeline, not the last, so VAR="$(printf ... | grep -oP ... | grep -E '\.apk\.version$' | head -1)" exits non-zero when that grep matches nothing, even though `head` succeeded. With -e the step dies AT THE ASSIGNMENT — before reaching the `if` written to handle exactly the empty case. Which is what happened: v2026.09.09 predates sidecar assets, so its `.apk.version` grep matched nothing and the step aborted instead of falling through to the name-only branch I added in 9f3e0b8c for precisely that release. The transition case was described correctly in that commit message and then not handled in code. The other two assignments carried the same latent hazard and had simply never fired, because a release always has a tag_name and an .apk asset. So the step's documented promise — "degrades to an empty client/ (404 update channel) — never a wrong version — if no release or APK asset can be resolved" — was never actually reachable under pipefail. All three now carry `|| true`. Reproduced under the runner's exact shell before fixing: without `|| true` the script exits 1 with no output at all, proving it never reaches the branch; with it, the fallback runs and emits the name-only sidecar. Guarded, since the graceful degradation depends on this and the failure is invisible until the one release that triggers it: the new test asserts every command-substitution grep in that step ends with `|| true`, and was falsified by removing it from the sidecar line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 08:37:23 -04:00
bvandeusenandClaude Opus 5	90bb3538c6	feat(release): build a dev channel so testing stops requiring a release ... There was no test channel at all. release.yml ran only on main and tags, so no :dev image existed and no APK was produced outside a release — the only way to get a build onto a phone was to ship one, which made `main` the staging area by default. A push to dev now builds a signed APK, bundles it, and publishes :dev. Signed with the SAME key as release builds, deliberately. A differently signed APK cannot install over the stable app, so anyone moving between channels would have to uninstall and lose their local data. Same key means both directions work. :dev is published ALONE, with no per-commit tag. A rolling channel is rolling by definition; a commit-addressable image for it would be a rollback target nobody ever pulls, kept forever. Recovery on dev is to fix forward, and that is a deliberate trade rather than an omission. The channel is derived from the REF, not the commit, which is why it is computed in the workflow and not in ci/version.sh. The same commit built on dev and on main reports the same version NAME and differs only in the channel field — that separation is the entire point of keeping the three values apart. What this repo deliberately does NOT get: a cross-repo dispatch to refresh the channel when its bundled APK is rebuilt. That mechanism exists elsewhere in the family because the app and server live in separate repos, and a channel that can only be refreshed by an unrelated commit is not a channel. Minstrel is a monorepo — one push builds the APK and the image in the same run from the same commit, so the channel cannot go stale against its own artifact. The requirement is met structurally; copying the mechanism would add a moving part to fix a problem that does not exist here. Two guards, for the two ways this wiring can fail quietly: A dev push must never move :latest. That would ship untested code to every stable operator on their next pull, with the build green and the image perfectly valid — just the wrong audience. Nothing else in the suite would notice. The two bundling paths must stay mutually exclusive. The rebundle step is now gated to main specifically, not to "not a tag": under the looser condition a dev push would run BOTH steps, staging its fresh APK and then overwriting it with the previous release's. The image still builds, the sidecar still parses, and the channel whose whole job is being current quietly serves stale art. Both falsified against the regressions they name before committing. Scribe task #3819, milestone #390. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-09 22:47:42 -04:00
bvandeusenandClaude Opus 5	eaf4654c0a	test(release): make the version derivation executable, and guard it on dev ... Steps 1 and 2 of this milestone shipped with no CI coverage at all, and the reason generalises: release.yml triggers only on main and tags, so nothing inside it is exercised until a release is already running. That is the worst place in the repo to be unguarded, because the failure mode is silence — a version nobody can compare looks exactly like being up to date, and nobody reports an update they were never offered. The fix is not a test that reads YAML. The derivation moved into ci/version.sh, so it can be RUN, and internal/server/release_version_test.go runs it on every push. release.yml now calls the same script, so the thing that ships and the thing under test are one artifact rather than two copies that agree until they don't. test-go.yml gains 'ci/**' and '.gitea/workflows/release.yml' in its paths. Without that the guard exists but never fires on the changes it protects, which is the same nothing it replaces. What is pinned, and why each one: - HHMM is zero-padded. A build at 00:42 must emit "0042"; a stripped leading zero shifts the segment two orders of magnitude and reverses comparisons against every other build that day. It only bites for a tenth of the day, so it will not be found by chance. - The name derives from the COMMIT and the code from the BUILD. Asserted by holding one clock and moving the other: the name must not move, the code must. - The code clears 1895, the highest versionCode the retired commit-count scheme shipped. Below that Android refuses the upgrade as a downgrade and the channel becomes a one-way door. - The tag is the name with a `v`, never chosen. - release.yml still calls the script, and does not derive a commit count again. This pins the WIRING: without it every other assertion keeps passing while the shipped path silently drifts out of coverage. The script rejects unusable clocks rather than emitting something plausible, and those rejections are tested — a guard that cannot fail is worse than none, because it reads as coverage. Falsified before committing rather than after: ran the script against good and broken inputs and watched all three failure paths fire; verified every asserted value by executing it rather than by reading it; and checked the two workflow predicates catch their regressions while staying immune to a comment that merely names the old formula. Step 5 of 5 — Scribe task #3812, milestone #390. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-09 22:11:51 -04:00