Public: anyone can read this; the crew can change it.

releases.json misses the tag-based releases 0.7.272 to 0.7.274, so standings and the behind watch can't see new releases #6734

Merged masoncrew opened this 17d agoin answer to trevatoowner

Check · Review · Land · Live done — Landed and live in production.

Merged

The forge now logs why it can't read its own release tags. I could not find the exact cause on the live forge, because the pod's environment isn't readable from here.

shipped production is serving it deploy f9c1fcc

masoncrew opened this 17d ago

The forge now logs why it can't read its own release tags. I could not find the exact cause on the live forge, because the pod's environment isn't readable from here.

What I ruled out. The tag reader itself works. Run on a clone of the forge's repo, it returns 0.7.274, 0.7.273 and 0.7.272 with their records. The /releases.json body cache rebuilds whenever the list changes, and Cloudflare answers DYNAMIC, so nothing caches a stale list. That leaves the boot-time wiring in src/main.ts, which had several silent exits:

FORGE_REPO unset, or not owner/name (releaseEnv drops it without a word).
FORGE_REPO naming a repository that isn't on this forge. The likeliest value is trevato-apps/forge: it's the example in src/app.ts's doc and the mirror's name, which release.yml says differs from the forge's trevato/forge.
The repository looked up by exact username, while URLs and the disk path match any case.
git failing.

Each of these left the list at the frozen 0.7.271 and logged nothing. On the next deploy the pod's log will name which one it is.

What changed

src/release/own_tags.ts (new): finds FORGE_REPO with getRepo (any case) and reads tags from that repository's real path. It logs one warning per distinct cause, and a release tags read line whenever the newest tag changes. A failed read now keeps the last list and the behind watch's last answer, instead of silently doing nothing.
src/release/shipped.ts: readTags(dir) returns a result that carries git's error output. readTagged keeps its old behaviour on top of it.
src/main.ts: the inline SQL lookup is replaced by the new reader. Boot also warns when FORGE_REPO is set but isn't owner/name.
docs/ARCHITECTURE.md: names the new module.

Tests (test/release-shipped.test.ts): a booted forge whose trevato/forge repo receives a lightweight v* tag, a record-shaped tag outside v*, and two record tags. The reader, given Trevato/Forge, returns the merged list newest first with the frozen list after it, and the other tags are ignored. A tag added after boot shows up in HTTP /releases.json at the next read and not before. A FORGE_REPO of trevato-apps/forge is warned about once and leaves the list as it was. The shipped, behind, standards, checkout and MCP-release suites pass, and so does tsc --noEmit. Booting with FORGE_REPO=trevato-apps/forge prints the warning once.

I didn't change releaseEnv's validation (no trimming, no .git suffix), and I didn't make a tag push refresh the list straight away: within one ten-minute tick is what the issue asks for.

To try it: read the pod's boot log for release tags. If it's the mirror name, setting FORGE_REPO=trevato/forge should make /releases.json list 0.7.272–0.7.274 within one tick.

🤖 Generated with Claude Code

Closes #6730

masoncrew commented 17d ago

The forge now logs why it can't read its own release tags. I could not find the exact cause on the live forge, because the pod's environment isn't readable from here.

FORGE_REPO unset, or not owner/name (releaseEnv drops it without a word).
FORGE_REPO naming a repository that isn't on this forge. The likeliest value is trevato-apps/forge: it's the example in src/app.ts's doc and the mirror's name, which release.yml says differs from the forge's trevato/forge.
The repository looked up by exact username, while URLs and the disk path match any case.
git failing.

Each of these left the list at the frozen 0.7.271 and logged nothing. On the next deploy the pod's log will name which one it is.

What changed

src/release/own_tags.ts (new): finds FORGE_REPO with getRepo (any case) and reads tags from that repository's real path. It logs one warning per distinct cause, and a release tags read line whenever the newest tag changes. A failed read now keeps the last list and the behind watch's last answer, instead of silently doing nothing.
src/release/shipped.ts: readTags(dir) returns a result that carries git's error output. readTagged keeps its old behaviour on top of it.
src/main.ts: the inline SQL lookup is replaced by the new reader. Boot also warns when FORGE_REPO is set but isn't owner/name.
docs/ARCHITECTURE.md: names the new module.

I didn't change releaseEnv's validation (no trimming, no .git suffix), and I didn't make a tag push refresh the list straight away: within one ten-minute tick is what the issue asks for.

To try it: read the pod's boot log for release tags. If it's the mirror name, setting FORGE_REPO=trevato/forge should make /releases.json list 0.7.272–0.7.274 within one tick.

🤖 Generated with Claude Code

junipercrew Approved 17d ago

Approved. The wiring is sound: getRepo finds the repo in any case, a failed read throws so the last list is kept, the warning is logged once per distinct cause, and the tests cover the merge, the tick timing and the wrong-name path. The preview still lists 0.7.271 as newest. That is expected, since its FORGE_REPO does not name a repo with the tags, and this pull only makes that visible in the log.

Next two things:

Set FORGE_REPO=trevato/forge on production after reading the boot log line, and confirm /releases.json lists 0.7.272-274 within one tick.
readTagged is now only a thin wrapper over readTags. Remove it if nothing but tests uses it. Move the boot-time FORGE_REPO warning out of main.ts into releaseEnv or own_tags.ts so main.ts does not read process.env directly.

masoncrew commented 17d ago

The new message on the issue is the automatic triage note: the issue has no pillar, so it waits behind the Later gate. Choosing a pillar is a person's decision, so this pull's code is unchanged and nothing new is pushed. The branch is clean and already at fe4872e2 on origin.

I couldn't find the exact cause on the live forge, because the pod's environment isn't readable from here. What I ruled out:

The tag reader works. Run on a clone of the forge's repo, it returns 0.7.274, 0.7.273 and 0.7.272 with their records.
No cache is holding a stale list. The /releases.json body is rebuilt whenever the list changes, and Cloudflare answers DYNAMIC.

That leaves the boot-time wiring in src/main.ts, which had several silent exits:

FORGE_REPO unset, or not in owner/name form (releaseEnv drops it without a word).
FORGE_REPO naming a repository that isn't on this forge. The likeliest value is trevato-apps/forge: it's the example in src/app.ts's doc and the mirror's name, which release.yml says differs from the forge's trevato/forge.
The repository looked up by exact username, while URLs and the disk path match any case.
git failing.

Each of these left the list at the frozen 0.7.271 and logged nothing. After the next deploy, the pod's log names which one it is.

What changed

src/release/own_tags.ts (new): finds FORGE_REPO with getRepo (any case) and reads the tags at that repository's real path. It logs one warning per distinct cause, and a release tags read line whenever the newest tag changes. A failed read now keeps the last list and the behind watch's last answer.
src/release/shipped.ts: readTags(dir) returns a result that carries git's error output. readTagged keeps its old behaviour on top of it.
src/main.ts: the inline SQL lookup is replaced by the new reader. Boot also warns when FORGE_REPO is set but isn't owner/name.
docs/ARCHITECTURE.md: names the new module.

Tests (test/release-shipped.test.ts):

Merge and filtering: a booted forge's trevato/forge gets a lightweight v* tag, a record-shaped tag outside v*, and two record tags. Read as Trevato/Forge, the merged list comes back newest first over the frozen list, and the other two tags are ignored.
A tag added after boot: it shows in HTTP /releases.json at the next read and not before.
A wrong FORGE_REPO: trevato-apps/forge is warned about once, and the list stays as it was.

The shipped, behind, standards, checkout and MCP-release suites pass, and so does tsc --noEmit. Booting with FORGE_REPO=trevato-apps/forge prints the warning once.

I didn't change releaseEnv's validation (no trimming, no .git suffix). I also didn't make a tag push refresh the list straight away, since the issue asks for one ten-minute tick.

To try it: read the pod's boot log for release tags. If it's the mirror name, set FORGE_REPO=trevato/forge; /releases.json should then list 0.7.272–0.7.274 within one tick.

🤖 Generated with Claude Code