From cb50e6ea60407f221736dc6bfe77f35e39a34320 Mon Sep 17 00:00:00 2001 From: pi Date: Thu, 28 May 2026 16:54:23 +0200 Subject: [PATCH] =?UTF-8?q?Cut=20v1.15.11c=20=E2=80=94=20re-tag=20of=20v1.?= =?UTF-8?q?15.12=20to=20fix=20versioning-scheme=20violation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The 2026-05-28 morning v1.15.12 release violated the project's v{opencode_version}[letter] tagging scheme: opencode-ai stayed at 1.15.11 upstream (no 1.15.12 exists on npm), so the third container build on opencode 1.15.11 should have been v1.15.11c. The commit message of the slipped tag (be2a168) itself said 'OPENCODE_VERSION stays at 1.15.11 (no upstream change)' — the slip was caught the same afternoon during a versioning audit. This release re-cuts at HEAD and supersedes v1.15.12. The slipped git tag and the eight v1.15.12* / latest* Docker Hub images remain as historical artifacts. Future builds on opencode 1.15.11 continue the letter sequence as v1.15.11d, v1.15.11e, etc; v1.15.12 will only be reused if and when opencode upstream actually releases 1.15.12. Includes everything in v1.15.12 plus the afternoon followup work: - CI: registry cache-export disabled (Hub 400 root-cause fix) - Docs: manual host-publish runbook + script archive - CI: workflow-level 3-attempt retry around buildx build --push AGENTS.md: new pre-flight check requirement under Versioning scheme documenting the slip as a cautionary example. Mandatory 'npm view opencode-ai version' check before any non-letter-suffix tag. CHANGELOG: new v1.15.11c block with full content list; v1.15.12 block gets a note documenting the supersession. --- AGENTS.md | 7 +++++++ CHANGELOG.md | 27 +++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index a3e14fd..c9579a8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -27,6 +27,13 @@ Tags follow `v{opencode_version}[letter]` — e.g. `v1.14.20` for the first buil - **No letter suffix** on the first build of a new opencode version — the bare `v{opencode_version}` tag is the canonical release. - **Letter suffix is the build ordinal**, starting at `b` for the second build. The letter `a` is **never used** — think of the suffix as counting rebuilds: `b = 2nd, c = 3rd, d = 4th, …`. For opencode version `1.14.20`: first build `v1.14.20`, second `v1.14.20b`, third `v1.14.20c`, and so on. - A letter suffix is only used for container-level rebuilds — tooling changes, CVE fixes, doc-driven rebuilds, entrypoint bugfixes — that don't change the underlying opencode version. +- **Pre-flight check before cutting any non-letter-suffixed tag** — verify the bump is real: + ```bash + npm view opencode-ai version # must equal the X.Y.Z in your tag + ``` + If the npm version equals the *previous* release's `X.Y.Z`, you're cutting a letter-suffix rebuild (`vX.Y.Zc`, `vX.Y.Zd`, …), not a new minor. **A bare `vX.Y.Z` tag is a claim that opencode upstream just released `X.Y.Z`** — if that claim is wrong, future opencode releases will collide with your tag namespace and the version-tracking story breaks. + + Cautionary example: 2026-05-28 morning, `v1.15.12` was cut while opencode-ai was still at `1.15.11`. The commit message itself acknowledged "OPENCODE_VERSION stays at 1.15.11" but tagged `v1.15.12` anyway. Re-cut as `v1.15.11c` the same afternoon (see CHANGELOG). The `v1.15.12` git tag and Hub images stayed as historical artifacts; the slip cost a CI cycle and a CHANGELOG-rewrite. **Run the npm view check at the top of every release-day cut.** CI produces eight Docker Hub tags per release: `vX.Y.Z[n]`, `latest`, `vX.Y.Z[n]-omos`, `latest-omos`, `vX.Y.Z[n]-with-pi`, `latest-with-pi`, `vX.Y.Z[n]-omos-with-pi`, `latest-omos-with-pi` — one tag pair (versioned + floating alias) per build variant. diff --git a/CHANGELOG.md b/CHANGELOG.md index a04d268..da929e1 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -8,6 +8,21 @@ Tags follow `v{opencode_version}[letter]` — bare tag for the first build on a ## Unreleased +_(no changes since v1.15.11c)_ + +## v1.15.11c — 2026-05-28 + +**Re-cut of v1.15.12 to fix a versioning-scheme violation.** The morning's v1.15.12 release was tagged in error: `opencode-ai` stayed at `1.15.11` upstream (no 1.15.12 exists on npm), so per the project's `v{opencode_version}[letter]` scheme this should have been the third container build on opencode 1.15.11 — `v1.15.11c` — not a new minor version bump. The `v1.15.12` git tag and the eight `v1.15.12*` / `latest*` Docker Hub images remain as historical artifacts but are superseded by this release. Future builds on opencode 1.15.11 continue the letter sequence as `v1.15.11d`, `v1.15.11e`, … — v1.15.12 will only be reused if and when opencode upstream actually releases 1.15.12. + +Content inherited from v1.15.12 (see that block below for the full diagnostic chain on the v4.0.0 pin disproof and the manual host-side publish): + +- pi `0.75.5` → `0.76.0`. +- `setup-buildx-action` pin reverted from `@v4.0.0` back to `@v4` (the v1.15.11b regression hypothesis was disproven). +- Inheritance from base: SSH ControlMaster on a writable socket path, gitleaks, git-crypt. +- Cache-hit silent same-bytes regression fix carried forward from v0.75.5b's pattern. + +Additional changes since v1.15.12 (afternoon 2026-05-28 followup work): + ### Hub-push regression — root cause identified, CI fixed The `400 Bad request` from `registry-1.docker.io` that broke CI publishing across runs #332/333/334/336 (and forced v1.15.12 to ship via manual host-side push) is **buildkit's registry cache-export with `mode=max`**, not the image push itself. @@ -36,16 +51,28 @@ Next tag push (e.g. v1.15.13) is expected to publish cleanly via Gitea CI again. - ~~`catthehacker/ubuntu:act-latest`~~ / ~~act-runner egress~~ — manual publish from host reproduced the same 400, ruling out runner-side network. Not the cause. - **Confirmed:** buildkit cache-export protocol (mode=max) hitting Hub-CDN edge rejection. Workaround: don't export cache to registry. Long-term: track moby/buildkit upstream for protocol fix or switch to GHA cache (not portable to Gitea Actions). +### Docs: manual host-publish runbook + script archive + +- `docs/manual-host-publish.sh` — the literal script that shipped v1.15.12 from a developer Mac via Orbstack, preserved as-is. +- `docs/manual-host-publish.md` — runbook explaining when to reach for the escape hatch, the four constants to edit (`RELEASE_TAG`, `BASE_HASH`, `PI_VERSION`, `OMOS_VERSION`), three sources for `BASE_HASH` (CI's `base-decide` log = canonical, Hub `base-latest` probe, local recompute matching CI's exact recipe including `__pycache__`/`.DS_Store`/`._*` junk filters), and adaptations for pi-devbox / letter-suffix rebuilds / partial-failure single-variant recovery. +- `AGENTS.md` — new Critical conventions bullet documenting that `cache-from`/`cache-to` is currently disabled, why, and the re-enable condition. + ### CI: workflow-level retry around `docker buildx build --push` All five push steps in `.gitea/workflows/docker-publish-split.yml` (1 base + 4 variants) are now wrapped in a 3-attempt retry loop with backoff (15s, 30s) as belt-and-braces against transient `registry-1.docker.io` blips. Replaces the `docker/build-push-action@v7` invocations with `shell: bash` steps that run `docker buildx build --push` directly so the loop is visible and tweakable. Smoke-test build steps (`load: true`, no push) are unchanged — they don't suffer from registry-side flakiness. Does **not** mask deterministic failures: a true regression (e.g. the cache-export 400 documented above) will fail all 3 attempts identically and the job still fails by design. Belt-and-braces with the workflow-level retry-on-failure rerun heuristic in the `ci-release-watcher` skill, which catches transient-shaped runner-side failures separately. No image-side change. +### AGENTS.md addition: pre-flight scheme check + +New "Versioning scheme" subsection documenting the **mandatory `npm view opencode-ai version` pre-flight check** before cutting any non-letter-suffixed tag, with this slip cited as the cautionary example. + --- ## v1.15.12 — 2026-05-28 +> **Note (2026-05-28 PM):** this tag violates the project's `v{opencode_version}[letter]` versioning scheme — there is no `opencode-ai@1.15.12` on npm; OPENCODE_VERSION stayed at 1.15.11 across this build. Re-cut as `v1.15.11c` at HEAD per the scheme. The git tag and Hub images for `v1.15.12*` remain as historical artifacts but are superseded by `v1.15.11c`. See the `v1.15.11c` block above for the corrected release notes. + Manual-published release. Reverts the `setup-buildx-action@v4.0.0` pin from v1.15.11b (hypothesis was disproven — see below) and bumps the bundled `pi-coding-agent` to 0.76.0 via the floating `PI_VERSION=latest` resolution. ### Why "manual-published"