v1.15.4: bump opencode 1.15.3 -> 1.15.4

Bundles with the CI hardening landed on main since v1.15.3 (T14/T15 in the operator backlog): - Pinned crane install in promote-base-latest (replaces flaky imjasonh/setup-crane@v0.4 that depends on api.github.com/releases/latest at runtime and periodically rate-limits) - Skip promote-base-latest on cache-hit base builds (need_build='false') These will be exercised on this release run \u2014 if the base hash hasn't drifted since v1.15.3 (likely cache hit), promote-base-latest should SKIP rather than RUN, and update-description picks up the new tag.
2026-05-18 21:51:15 +02:00
parent 18b9c9c549
commit 60eb49469e
2 changed files with 8 additions and 4 deletions
@@ -8,10 +8,14 @@ Tags follow `v{opencode_version}[letter]` — bare tag for the first build on a

 ## Unreleased

-CI hardening for the `promote-base-latest` job. No image-side changes — these are workflow-only edits and won't trigger a tag.
+## v1.15.4 — 2026-05-18

- **Replaced `imjasonh/setup-crane@v0.4` with a direct pinned crane install.** The action's bootstrap script calls `api.github.com/.../releases/latest` to discover what crane version to install. That call periodically rate-limits and produces `tag=null` → the action downloads `releases/download/null/...` → 404 → `gzip: unexpected end of file` → exit 2. Hit this on the v1.15.3 release run (cosmetic failure — base-latest was already correct). Now we curl + extract crane v0.21.6 directly into `/usr/local/bin/`. Bump `CRANE_VERSION` deliberately when wanting updates, same pattern as the other GitHub-sourced binaries in the Dockerfile layer.
- **Gated `promote-base-latest` on `need_build == 'true'`.** When the base layer hash hasn't changed (cache-hit on the existing `base-<hash>` from a previous run), `base-latest` already points at the correct digest, so the retag is a tautology. Skipping in that case removes a class of cosmetic failure (no-op-that-fails). Manual `workflow_dispatch` with `promote_latest: true` overrides the gate as an escape hatch for hand-recovery scenarios. Tagged releases that genuinely rebuild the base still promote as before.
+opencode 1.15.3 → 1.15.4 bump (one upstream patch release), bundled with the CI hardening that landed on main between v1.15.3 and now.
+
+- **Bump:** opencode 1.15.3 → 1.15.4 (`OPENCODE_VERSION` in `Dockerfile.variant`).
+- **CI: pinned crane install in `promote-base-latest`.** Replaced `imjasonh/setup-crane@v0.4` with a direct `curl + tar` install pinned to crane v0.21.6. The action's bootstrap script calls `api.github.com/.../releases/latest` to discover what crane version to install. That call periodically rate-limits and produces `tag=null` → the action downloads `releases/download/null/...` → 404 → `gzip: unexpected end of file` → exit 2. We hit this on v1.15.3 (cosmetic failure since base-latest was already correct from cache hit). Pinned install removes the runtime GitHub API dependency entirely. Bump `CRANE_VERSION` deliberately when wanting updates, same pattern as the other GitHub-sourced binaries in the Dockerfile layer.
+- **CI: skip `promote-base-latest` on cache-hit base builds.** When the base layer hash hasn't changed (cache-hit on the existing `base-<hash>` from a previous run), `base-latest` already points at the correct digest, so the retag is a tautology. Job now skipped entirely when `needs.base-decide.outputs.need_build == 'false'`. Manual `workflow_dispatch` with `promote_latest: true` overrides the gate as an escape hatch for hand-recovery scenarios.
+- No image-side changes from the v1.15.3 baseline beyond the opencode npm version. Smoke thresholds unchanged.

 ## v1.15.3 — 2026-05-16