h-dv/code-index

Watch

Fork 0

Publish `install.sh` as a release asset, so an installer can be pinned to a release instead of tracking master #261

New issue

Closed

opened 2026-09-10 21:26:57 +02:00 by buildagent · 1 comment

buildagent commented

2026-09-10 21:26:57 +02:00

Member

What ships now

install.sh (v0.28.0) is the install and update mechanism. The
documented one-liner fetches it from the default branch:

curl -sSfL https://git.h-dv.de/h-dv/code-index/raw/branch/master/install.sh | sh

That is correct as far as it goes — the script asks the release API for
the latest tag, so it installs a released version, not master's
build. But the script itself is whatever master says at the moment you
curl it.

What is missing

There is no way to pin the installer. An operator who wants a
reproducible provisioning step — a Dockerfile, an image build, a
locked-down runner — has to either vendor the script or accept that the
URL's contents move.

Publishing install.sh as a release asset beside the archives fixes
that:

curl -sSfL https://git.h-dv.de/h-dv/code-index/releases/download/v0.28.0/install.sh | sh

Why it was not done in v0.28.0

Deliberately, and the reason is worth recording rather than repeating:
adding a new required asset to release.yml in the same change that
ships the mechanism means the first release to carry it is also the
first release that can fail on it. The required-asset audit is strict by
design (it refuses to publish a set it could not count), so a wiring
mistake costs a whole release cycle. The raw-URL path delivers the
capability today; pinning is an addition, not a fix.

Shape of the work

Upload install.sh alongside the archives in the release job.
Add it to the required-asset audit — and derive the requirement, do
not type it. The audit already enumerates packages from
tests/packages/*/plugin.toml; the installer is a single known file,
so the honest form is a presence check with a reason string, not a
list entry that can be forgotten.
Point the README one-liner at the release URL, keeping the
branch URL documented as the "always latest" form. Both, labelled —
they answer different questions.

The trap to avoid

The installer's platform table is graded against release.yml's
matrices by crates/cli/tests/installer_targets.rs. If a copy of
install.sh is generated or rewritten during the release, that gate is
grading the repository's copy while operators run the published one.
Publish the file verbatim, or the gate becomes vacuous — which is the
precision_gate-shaped hazard: a check correctly implemented over a
domain that cannot contain the failure.

#59 (macOS is not published; the installer refuses it by name)
The de.h-dv.ruby omission, which is why the required-asset audit
derives its population instead of listing it.

## What ships now `install.sh` (v0.28.0) is the install and update mechanism. The documented one-liner fetches it from the default branch: ```bash curl -sSfL https://git.h-dv.de/h-dv/code-index/raw/branch/master/install.sh | sh ``` That is correct as far as it goes — the script asks the release API for the latest **tag**, so it installs a released version, not master's build. But the *script itself* is whatever master says at the moment you curl it. ## What is missing There is no way to pin the installer. An operator who wants a reproducible provisioning step — a Dockerfile, an image build, a locked-down runner — has to either vendor the script or accept that the URL's contents move. Publishing `install.sh` as a release asset beside the archives fixes that: ```bash curl -sSfL https://git.h-dv.de/h-dv/code-index/releases/download/v0.28.0/install.sh | sh ``` ## Why it was not done in v0.28.0 Deliberately, and the reason is worth recording rather than repeating: adding a **new required asset** to `release.yml` in the same change that ships the mechanism means the first release to carry it is also the first release that can fail on it. The required-asset audit is strict by design (it refuses to publish a set it could not count), so a wiring mistake costs a whole release cycle. The raw-URL path delivers the capability today; pinning is an addition, not a fix. ## Shape of the work 1. Upload `install.sh` alongside the archives in the release job. 2. Add it to the required-asset audit — and derive the requirement, do not type it. The audit already enumerates packages from `tests/packages/*/plugin.toml`; the installer is a single known file, so the honest form is a presence check with a reason string, not a list entry that can be forgotten. 3. Point the README one-liner at the release URL, keeping the branch URL documented as the "always latest" form. Both, labelled — they answer different questions. ## The trap to avoid The installer's platform table is graded against `release.yml`'s matrices by `crates/cli/tests/installer_targets.rs`. If a *copy* of `install.sh` is generated or rewritten during the release, that gate is grading the repository's copy while operators run the published one. Publish the file verbatim, or the gate becomes vacuous — which is the `precision_gate`-shaped hazard: a check correctly implemented over a domain that cannot contain the failure. ## Related - #59 (macOS is not published; the installer refuses it by name) - The `de.h-dv.ruby` omission, which is why the required-asset audit derives its population instead of listing it.

buildagent referenced this issue

2026-09-10 22:11:20 +02:00

code-index-plugin-host cannot say which build it is — three of four shipped binaries answer --version, the fourth exits 21 with usage #262

dhoyer referenced this issue from a commit

2026-09-10 22:34:48 +02:00

feat: install and update with one command, and the platform table is graded

buildagent referenced this issue from a commit

2026-09-11 11:17:06 +02:00

fix: bind query evidence and Python imports to proven index state

buildagent referenced this issue

2026-09-11 11:17:22 +02:00

Bind query evidence and Python imports to proven index state #264

buildagent commented

2026-09-11 20:24:42 +02:00

Author

Member

Released in v0.28.1, build 340a75a, via #264 and #265. Release CI passed, including the Windows archive round-trip smoke test. The release now contains install.sh and its SHA-256 sidecar. Downloaded bytes match the installer at the exact tag, the checksum passes, and that published script successfully installed v0.28.1 into an isolated prefix and passed --check. Installed executables match the downloaded archive bytes. The documented pin covers both the installer URL and --tag. Closing after testing the public assets.

Released in [v0.28.1](https://git.h-dv.de/h-dv/code-index/releases/tag/v0.28.1), build `340a75a`, via #264 and #265. [Release CI](https://git.h-dv.de/h-dv/code-index/actions/runs/752) passed, including the Windows archive round-trip smoke test. The release now contains install.sh and its SHA-256 sidecar. Downloaded bytes match the installer at the exact tag, the checksum passes, and that published script successfully installed v0.28.1 into an isolated prefix and passed --check. Installed executables match the downloaded archive bytes. The documented pin covers both the installer URL and --tag. Closing after testing the public assets.

buildagent closed this issue

2026-09-11 20:24:42 +02:00

~~buildagent referenced this issue 2026-09-11 20:25:15 +02:00~~

Prepare v0.28.2: Python receiver fix and historical acceptance #266

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

h-dv/code-index#261

No description provided.

Rows
Columns

Publish install.sh as a release asset, so an installer can be pinned to a release instead of tracking master #261