ci: pin the SpacetimeDB CLI to 2.8.1 #1

Merged

aiko merged 1 commit from ci/pin-spacetime-2.8.1 into main

2026-08-13 14:08:03 +00:00

aiko commented

2026-08-13 13:19:56 +00:00

Owner

Pins the SpacetimeDB CLI to an explicit version instead of taking whatever upstream called latest on the day the image happened to be built.

Merge and rebuild this image before merging the matching mobrule crate bump. Workflows there consume mobrule-ci:latest, so the rebuild propagates on its own — but until it does, check-bindings-sync.sh will fail.

Why it is load-bearing

mobrule's check-bindings-sync.sh regenerates module_bindings/ using whatever CLI this image carries, then fails on any diff. Codegen output changes between CLI versions.

So an unpinned install means a routine image rebuild can redden every mobrule build with roughly 1,900 lines of binding drift, with no commit to point at. The existing -I 'generated using spacetimedb cli version' exclusion in that script only hides the version comment — it does nothing about changed trait impls.

This was reproduced rather than assumed: with 2.8.1 bindings staged and a 2.2.0 CLI active, the check fails with 28 files changed, 1932 deletions(-).

What changed

ARG SPACETIME_VERSION=2.8.1, so a bump is a one-line change with a commit attached
The installer has no version flag, so it installs latest and then pins through the CLI's own version manager (spacetime version install / version use)
A version assertion after the install: the build now fails if the pinned version is not what ends up on PATH, rather than shipping a silently wrong image

Verified

Built in a clean ubuntu:24.04 container:

spacetime Path: /root/.local/share/spacetime/bin/2.8.1/spacetimedb-cli
spacetimedb tool version 2.8.1; spacetimedb-lib version 2.8.1;

The assertion was exercised by the build itself — the grep runs on every build, so a mismatch fails the layer.

Why 2.8.1 specifically

Not 2.7.0: it swapped in upstream jsonwebtoken, which cannot validate a JWT whose header carries non-string extra fields. Reverted in 2.7.1, so anything from 2.7.1 up is safe.

The version here should track the spacetimedb crate version in mobrule. Bump both in the same change.

Pins the SpacetimeDB CLI to an explicit version instead of taking whatever upstream called latest on the day the image happened to be built. **Merge and rebuild this image before merging the matching `mobrule` crate bump.** Workflows there consume `mobrule-ci:latest`, so the rebuild propagates on its own — but until it does, `check-bindings-sync.sh` will fail. ## Why it is load-bearing `mobrule`'s `check-bindings-sync.sh` regenerates `module_bindings/` using whatever CLI this image carries, then fails on any diff. Codegen output changes between CLI versions. So an unpinned install means a routine image rebuild can redden every `mobrule` build with roughly 1,900 lines of binding drift, with no commit to point at. The existing `-I 'generated using spacetimedb cli version'` exclusion in that script only hides the version comment — it does nothing about changed trait impls. This was reproduced rather than assumed: with 2.8.1 bindings staged and a 2.2.0 CLI active, the check fails with `28 files changed, 1932 deletions(-)`. ## What changed - `ARG SPACETIME_VERSION=2.8.1`, so a bump is a one-line change with a commit attached - The installer has no version flag, so it installs latest and then pins through the CLI's own version manager (`spacetime version install` / `version use`) - A version assertion after the install: the build now fails if the pinned version is not what ends up on `PATH`, rather than shipping a silently wrong image ## Verified Built in a clean `ubuntu:24.04` container: ``` spacetime Path: /root/.local/share/spacetime/bin/2.8.1/spacetimedb-cli spacetimedb tool version 2.8.1; spacetimedb-lib version 2.8.1; ``` The assertion was exercised by the build itself — the `grep` runs on every build, so a mismatch fails the layer. ## Why 2.8.1 specifically Not 2.7.0: it swapped in upstream `jsonwebtoken`, which cannot validate a JWT whose header carries non-string extra fields. Reverted in 2.7.1, so anything from 2.7.1 up is safe. The version here should track the `spacetimedb` crate version in `mobrule`. Bump both in the same change.

aiko added 1 commit

2026-08-13 13:19:56 +00:00

ci: pin the SpacetimeDB CLI to 2.8.1 4ea6f0495e

The installer was run unpinned, so the CLI baked into the image was whatever
upstream called latest on the day it was built, and nothing recorded which
version that was.

That matters because mobrule's check-bindings-sync.sh regenerates
module_bindings/ with this image's CLI and fails on any diff. Codegen output
changes between CLI versions, so rebuilding the image could redden every
mobrule build with ~1900 lines of binding drift and no commit to blame.

The installer has no version flag, so install latest and then pin through the
CLI's own version manager. The version check after it is deliberate: a silently
wrong version now fails the build instead of shipping.

Verified in a clean ubuntu:24.04 container: spacetimedb tool version 2.8.1.

aiko merged commit 238dfe87d9 into main

2026-08-13 14:08:03 +00:00

aiko referenced this pull request from a commit

2026-08-13 14:08:04 +00:00

Merge pull request 'ci: pin the SpacetimeDB CLI to 2.8.1' (#1) from ci/pin-spacetime-2.8.1 into main