bvandeusenandClaude Opus 5
c2fdc05e5c
Android / Build, or is the channel already serving this? (push) Successful in 3s
CI & Build / Build now, or wait for Android? (push) Successful in 3s
CI & Build / Python lint (push) Successful in 4s
Desktop (Tauri) / Build, or is the channel already serving this? (push) Successful in 4s
CI & Build / TypeScript typecheck (push) Successful in 7s
CI & Build / Python tests (push) Successful in 12s
CI & Build / integration (push) Successful in 18s
CI & Build / Build & push image (push) Skipped
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 3m0s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 5m17s
Desktop (Tauri) / Update manifest (push) Successful in 4s
Android / Kotlin + Rust (APK) (push) Successful in 8m4s
Step 7 of M314, the last one. Rule 22 — the old path comes out completely. ## A release stops building `desktop.yml` no longer triggers on `v*`, and its two `Publish release` steps are gone. `ci.yml` lost its tag trigger in step 6. So a tag now reaches exactly one lane: the new `release.yml`, which builds nothing. That is not a simplification for its own sake. The merge to `main` already published everything a user can receive — `:latest` + `:<sha>`, both channel feeds, the updater manifest. A tag rebuilding that source produces identical artifacts under identical names and re-pushes `:<sha>` with different bytes, which rule 145 forbids even when they match. ## So what a release is FOR The changelog (note 3127 §5). Two halves to "what am I running", and the version answers only the first: which build is this (the footer, /api/config, the APK's versionName) and what is in it that was not in the one I ran last month (nothing, until now). `packaging/release-notes.sh` derives it from git rather than a hand-maintained CHANGELOG, which drifts into recording what someone MEANT to ship. Capped at 60 entries with the omitted count stated — the first dated release spans 181 commits since `v0.1.0`, and a truncated list that does not say it is truncated is a lie. It publishes through `publish-release.sh` rather than making its own API calls, for the create-or-PATCH-on-409 path: a fixed-tag release that only ever POSTs keeps whatever body its first run wrote, which is #2182, and reimplementing that correctly in a second place is how it comes back. ## Retired `MANIFEST_TAG` and the whole branch behind it. It let the manifest live on a `stable` pointer release while the bundles sat on a versioned one — a split step 3 removed when `stable` started holding its own bundles. Nothing had passed it since; a parameter that can only ever receive its own default is a branch nobody exercises and a comment that goes stale, and its stale text was still telling readers the installable builds live on the versioned releases. `desktop/src-tauri/Cargo.toml`'s version and `thoughtsync/__init__.py`'s both now say out loud that they are not shipped values. The Cargo one carries the history worth keeping: the old scheme took its base from that line, so `0.2.<run>` on dev outranked a bare `0.2.0` on main, and the remedy was "remember to bump the minor before tagging" — documented in a comment, enforced nowhere. #2183 is what that looked like in the field. **That ritual is now formally dead**, and this is the deliberate act of killing it rather than a side effect. ## Still there on purpose `install.sh`'s transitional stable fallback. It cannot go until `main` has published to `stable` at least once, and that is gated on an operator request. Removing it now would break the DEFAULT install channel. #3147 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
69 lines
2.9 KiB
YAML
69 lines
2.9 KiB
YAML
name: Release
|
|
|
|
# A RELEASE BUILDS NOTHING. That is the whole point of this lane (M314 step 7).
|
|
#
|
|
# The merge to `main` already published everything a user can receive: the server
|
|
# image as `:latest` + `:<sha>`, the desktop bundles and the APK to the `stable`
|
|
# channel, and the updater manifest that advertises them. A tag rebuilding that same
|
|
# source would produce identical artifacts under identical names, and would re-push
|
|
# `:<sha>` with different bytes — which rule 145 forbids even when they match.
|
|
#
|
|
# So the tag is a BOOKMARK, and this lane gives it the only job it has left: saying
|
|
# what was in it. Note 3127 §5 — there are two halves to "what am I running", and
|
|
# the version answers only the first:
|
|
#
|
|
# which build is this? the footer, /api/config, the APK's versionName
|
|
# what changed since the one ← this
|
|
# I was running last month?
|
|
#
|
|
# Cutting the tag is the operator's act (rule 2). This only responds to one.
|
|
#
|
|
# THE TAG IS NOT AN IMAGE TAG and never becomes one. `ci.yml` does not trigger on
|
|
# tags at all. The image is addressed by channel or by commit; the release by date.
|
|
# Same string as the artifact version (rule 148, `vYYYY.MM.DD.HHMM`), different
|
|
# system.
|
|
|
|
on:
|
|
push:
|
|
tags: ["v*"]
|
|
|
|
permissions:
|
|
contents: write
|
|
|
|
jobs:
|
|
notes:
|
|
name: Write the changelog
|
|
runs-on: python-ci
|
|
container:
|
|
image: git.fabledsword.com/bvandeusen/ci-python:3.14
|
|
steps:
|
|
- uses: actions/checkout@v6
|
|
with:
|
|
# The whole history AND every tag: the notes are the commit range between
|
|
# this tag and the previous `v*` one, and neither end exists in a shallow
|
|
# clone. A depth-limited checkout here does not fail — it produces a
|
|
# shorter changelog, which is the kind of wrong nobody notices.
|
|
fetch-depth: 0
|
|
|
|
- name: Publish the release notes
|
|
env:
|
|
GITHUB_TOKEN: ${{ github.token }}
|
|
run: |
|
|
notes="$(sh packaging/release-notes.sh "$GITHUB_REF_NAME")"
|
|
echo "$notes"
|
|
echo "---"
|
|
|
|
# JSON-escaped HERE rather than in publish-release.sh, which cannot assume
|
|
# python3 is on PATH in the three images that call it. `json.dumps` then
|
|
# strip the surrounding quotes — the script supplies those.
|
|
RELEASE_BODY_JSON="$(printf '%s' "$notes" \
|
|
| python3 -c 'import json,sys; print(json.dumps(sys.stdin.read())[1:-1])')"
|
|
export RELEASE_BODY_JSON
|
|
|
|
# Through publish-release.sh for its create-or-PATCH-on-409 path: a
|
|
# release that is only ever POSTed keeps whatever body its first run
|
|
# wrote (#2182), so re-tagging or re-running must rewrite it. No bundles
|
|
# exist in this workspace, so its asset globs match nothing and it
|
|
# uploads none — which is the intended behaviour, not a side effect.
|
|
RELEASE_TAG="$GITHUB_REF_NAME" bash desktop/packaging/publish-release.sh
|