docs(agents): an image can reach the registry without CI #23

Merged

jlxq0 merged 1 commit from docs/images-can-bypass-ci into main

2026-08-28 01:39:27 +00:00

jlxq0 commented

2026-08-27 04:40:18 +00:00

Owner

Answers the open half of #14, and the answer is worse than the question.

`v0.2.5` and `v0.2.6` never went through CI


Actions tasks on 2026-08-16	6, all `cargo`, all `failure`, no `docker` job at all
first `docker` success after 2026-08-14	2026-08-18T01:29:29Z, two days later
`v0.2.5` image created	2026-08-16T01:31:54Z, 129 s after commit `09b5f5b`
`v0.2.6` image created	2026-08-16T06:14:30Z, 931 s after `c0a9353`

No CI run could have produced either. With CI red and an image appearing two minutes after a commit, that is a local docker build && push.

So the ancestry gate closes tags cut off unmerged branches and closes nothing here: it runs in CI, and this path never enters CI. Anything holding registry push credentials can publish, and the result is indistinguishable in the registry from a released image.

Recovery routes, both now closed by measurement:

OCI labels — both images carry none, consistent with predating 0ebc967 which added the LABEL block. No org.opencontainers.image.revision to read.
The embedded version — cannot discriminate, because of the next finding.

What remains is rebuilding a candidate commit and comparing layer digests. Not attempted, and deleting the images is not mine.

Every release v0.1.0 through v0.2.9 reported version `0.0.1`

Read out of the shipped binaries, not inferred:

v0.2.4  jmap-mcp/0.0.1      v0.2.7   jmap-mcp/0.0.1
v0.2.5  jmap-mcp/0.0.1      v0.2.14  jmap-mcp/0.2.14
v0.2.6  jmap-mcp/0.0.1      v0.2.16  jmap-mcp/0.2.16

Cargo.toml carried version = "0.0.1" from the initial commit until 0ebc967. CARGO_PKG_VERSION therefore went into the User-Agent sent to Logto and Stalwart, the OTLP service.version, and the version field main.rs serves. Ten releases whose self-reported version was wrong, with the tag and the registry both correct.

Already fixed: 0ebc967 set the real version and added test "${V#v}" = "$VERSION" to the tag build in the same commit. That check is the only thing preventing recurrence and it looks like ceremony beside a tag you just typed. The entry says not to remove it.

Where fleet facts live

Three sweeps of ~/.claude.json and project .mcp.json returned nothing while four sessions mounted this server. Mounts are at ~/Smithy/<name>_agent/wt/main/src/mcp.json under jlxq0/mantis#122. A sweep returning zero is the expected result of looking in the wrong place, and is indistinguishable from nothing mounting the server.

Docs only.

Refs #14

Answers the open half of #14, and the answer is worse than the question. ## `v0.2.5` and `v0.2.6` never went through CI | | | |---|---| | Actions tasks on 2026-08-16 | **6, all `cargo`, all `failure`, no `docker` job at all** | | first `docker` success after 2026-08-14 | 2026-08-18T01:29:29Z, two days later | | `v0.2.5` image created | 2026-08-16T01:31:54Z, **129 s** after commit `09b5f5b` | | `v0.2.6` image created | 2026-08-16T06:14:30Z, **931 s** after `c0a9353` | No CI run could have produced either. With CI red and an image appearing two minutes after a commit, that is a local `docker build && push`. **So the ancestry gate closes tags cut off unmerged branches and closes nothing here: it runs in CI, and this path never enters CI.** Anything holding registry push credentials can publish, and the result is indistinguishable in the registry from a released image. Recovery routes, both now closed by measurement: - **OCI labels** — both images carry none, consistent with predating `0ebc967` which added the `LABEL` block. No `org.opencontainers.image.revision` to read. - **The embedded version** — cannot discriminate, because of the next finding. What remains is rebuilding a candidate commit and comparing layer digests. Not attempted, and deleting the images is not mine. ## Every release v0.1.0 through v0.2.9 reported version `0.0.1` Read out of the shipped binaries, not inferred: ``` v0.2.4 jmap-mcp/0.0.1 v0.2.7 jmap-mcp/0.0.1 v0.2.5 jmap-mcp/0.0.1 v0.2.14 jmap-mcp/0.2.14 v0.2.6 jmap-mcp/0.0.1 v0.2.16 jmap-mcp/0.2.16 ``` `Cargo.toml` carried `version = "0.0.1"` from the initial commit until `0ebc967`. `CARGO_PKG_VERSION` therefore went into the `User-Agent` sent to Logto and Stalwart, the OTLP `service.version`, and the `version` field `main.rs` serves. Ten releases whose self-reported version was wrong, with the tag and the registry both correct. Already fixed: `0ebc967` set the real version **and** added `test "${V#v}" = "$VERSION"` to the tag build in the same commit. **That check is the only thing preventing recurrence and it looks like ceremony beside a tag you just typed.** The entry says not to remove it. ## Where fleet facts live Three sweeps of `~/.claude.json` and project `.mcp.json` returned nothing while four sessions mounted this server. Mounts are at `~/Smithy/<name>_agent/wt/main/src/mcp.json` under `jlxq0/mantis#122`. **A sweep returning zero is the expected result of looking in the wrong place, and is indistinguishable from nothing mounting the server.** Docs only. Refs #14

jlxq0 added 1 commit

2026-08-27 04:40:18 +00:00

docs(agents): an image can reach the registry without CI

CI / tag-ancestry (pull_request) Successful in 4s

Details

CI / cargo (pull_request) Successful in 1m46s

Details

CI / docker (pull_request) Successful in 15s

Details

eafd40090c

v0.2.5 and v0.2.6 have no tag and no Actions run that could have built them.
On 2026-08-16 the repo ran six tasks, all cargo, all failure, no docker job at
all, and the first docker success after 2026-08-14 was two days later. The
v0.2.5 image is 129s after commit 09b5f5b and v0.2.6 is 931s after c0a9353.
With CI red, that cadence is a local build and push.

So the tag-ancestry gate closes tags off unmerged branches and closes nothing
here: it runs in CI and this path never enters CI.

Also records that every release from v0.1.0 to v0.2.9 shipped a binary
reporting 0.0.1, read out of the shipped binaries rather than inferred.
Cargo.toml was 0.0.1 until 0ebc967, which set the real version and added the
tag-vs-version check in the same commit. That check is the only thing
preventing recurrence and it looks like ceremony.

And where agent MCP mounts live, since three sweeps of the wrong two locations
returned nothing and that is indistinguishable from nothing mounting it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>