INSTALLED_FROM records no forge, now that RIG_HOST decides which one a tree came from #124

New issue

Open

opened 2026-07-29 15:13:39 +00:00 by claude-bot-andresmgsl · 0 comments

claude-bot-andresmgsl commented

2026-07-29 15:13:39 +00:00

Member

install.sh writes INSTALLED_FROM beside every installed tree, and the comment
at :361-363 says why:

Record WHAT was installed, so a caller can assert it got what it asked for — an
installer invoked with stale env vars silently falls back to the defaults, and
INSTALLED_FROM is how that lie gets caught.

The value is $REPO@$REF. Since !114 the forge is a variable too, and the record
does not name it. Two live installs from this box, minutes apart:

RIG_HOST=https://forgejo.heavyduty.builders  →  INSTALLED_FROM: heavy-duty/rig@0.3.0
(default, GitHub)                            →  INSTALLED_FROM: heavy-duty/rig@0.3.1

Same repo, same format, different forges, and nothing in either file says which.

Why this is not cosmetic

A stale RIG_HOST is now precisely the failure the file exists to catch, and it
is the one input INSTALLED_FROM cannot report.

It also bites hardest exactly where the two forges disagree. This instance's
mirror lags — /releases/latest resolves 0.3.0 here and 0.3.1 on GitHub —
and releases are cut by CI that has never run here, so the lag is structural
rather than momentary. Two boxes can run curl … | bash with no RIG_REF, land
on genuinely different trees, and produce INSTALLED_FROM files that differ only
in a version number neither operator chose.

rig --version has the same gap: it reports the tree's VERSION and its path,
neither of which names an origin.

Spec

Record the host in INSTALLED_FROM when it is not the default, keeping the
existing format for the default so no current assertion changes:

heavy-duty/rig@0.3.1                                              # GitHub, unchanged
https://forgejo.heavyduty.builders/heavy-duty/rig@0.3.0           # non-default host

The existing local:$SRC form for RIG_INSTALL_SOURCE already establishes that
this field carries a qualified origin when there is one, so the shape is precedented.

Decide alongside: whether rig --version surfaces it too, or whether the file is
enough.

Tasks

Qualify INSTALLED_FROM with the host when RIG_HOST is not the default
Leave the default-host format byte-identical
Decide whether rig --version reports the origin
Extend test/release.sh's existing INSTALLED_FROM assertions

Acceptance criteria

A Forgejo-sourced tree's INSTALLED_FROM names the forge
A GitHub-sourced tree's INSTALLED_FROM is unchanged from today
Two installs of the same repo@ref from different forges produce different records
The drill's assert_installed_from still passes

Test plan

test/release.sh already drives real installs under a stub curl and asserts this
file; add a RIG_HOST arm. Live: install from both forges into throwaway roots
and diff the two records.

Dependencies

Follow-up to #111 / !114, raised in review by two reviewers and deferred as
non-blocking with the builder's agreement.

Filed under @andres's explicit authorization on !114 to create process issues
directly. No queue label applied — ready does not exist yet.

`install.sh` writes `INSTALLED_FROM` beside every installed tree, and the comment at `:361-363` says why: > Record WHAT was installed, so a caller can assert it got what it asked for — an > installer invoked with stale env vars silently falls back to the defaults, and > `INSTALLED_FROM` is how that lie gets caught. The value is `$REPO@$REF`. Since !114 the forge is a variable too, and the record does not name it. Two live installs from this box, minutes apart: ``` RIG_HOST=https://forgejo.heavyduty.builders → INSTALLED_FROM: heavy-duty/rig@0.3.0 (default, GitHub) → INSTALLED_FROM: heavy-duty/rig@0.3.1 ``` Same repo, same format, different forges, and nothing in either file says which. ## Why this is not cosmetic A stale `RIG_HOST` is now precisely the failure the file exists to catch, and it is the one input `INSTALLED_FROM` cannot report. It also bites hardest exactly where the two forges disagree. This instance's mirror lags — `/releases/latest` resolves `0.3.0` here and `0.3.1` on GitHub — and releases are cut by CI that has never run here, so the lag is structural rather than momentary. Two boxes can run `curl … | bash` with no `RIG_REF`, land on genuinely different trees, and produce `INSTALLED_FROM` files that differ only in a version number neither operator chose. `rig --version` has the same gap: it reports the tree's `VERSION` and its path, neither of which names an origin. ## Spec Record the host in `INSTALLED_FROM` when it is not the default, keeping the existing format for the default so no current assertion changes: ``` heavy-duty/rig@0.3.1 # GitHub, unchanged https://forgejo.heavyduty.builders/heavy-duty/rig@0.3.0 # non-default host ``` The existing `local:$SRC` form for `RIG_INSTALL_SOURCE` already establishes that this field carries a qualified origin when there is one, so the shape is precedented. Decide alongside: whether `rig --version` surfaces it too, or whether the file is enough. ## Tasks - [ ] Qualify `INSTALLED_FROM` with the host when `RIG_HOST` is not the default - [ ] Leave the default-host format byte-identical - [ ] Decide whether `rig --version` reports the origin - [ ] Extend `test/release.sh`'s existing `INSTALLED_FROM` assertions ## Acceptance criteria - [ ] A Forgejo-sourced tree's `INSTALLED_FROM` names the forge - [ ] A GitHub-sourced tree's `INSTALLED_FROM` is unchanged from today - [ ] Two installs of the same `repo@ref` from different forges produce different records - [ ] The drill's `assert_installed_from` still passes ## Test plan `test/release.sh` already drives real installs under a stub curl and asserts this file; add a `RIG_HOST` arm. Live: install from both forges into throwaway roots and diff the two records. ## Dependencies Follow-up to #111 / !114, raised in review by two reviewers and deferred as non-blocking with the builder's agreement. *Filed under @andres's explicit authorization on !114 to create process issues directly. No queue label applied — `ready` does not exist yet.*