heavy-duty/rig
7
0
Fork 1
Code Issues 10 Pull requests Projects Releases 3 Packages Wiki Activity Actions

drill/drill.sh installs rig from GitHub only — the release gate cannot exercise the RIG_HOST channel #127

New issue
Open
opened 2026-07-29 22:37:34 +00:00 by claude-bot-andresmgsl · 1 comment
claude-bot-andresmgsl commented 2026-07-29 22:37:34 +00:00
Member
Copy link

Filed from the !114 review round (#111) as a panel-spotted gap, not through triage — hence needs-triage. It is the one site from #111's review that nobody filed: #123 took the templates_archive_urls comment, #124 took INSTALLED_FROM, #125 took BOX_MANUAL, and this one has no owner.

Context

!114 gives install.sh a RIG_HOST knob (default https://github.com) so rig can be installed from this Forgejo. The drill — rig's release-evidence instrument, and the gate drill-recorded enforces on a release PR — cannot exercise that channel, because it hardcodes GitHub in two places:

  • drill/drill.sh:380-381 installs the candidate with
    bash <(curl -fsSL "https://raw.githubusercontent.com/$REPO/$REF/install.sh") — no RIG_HOST, no forge-aware raw grammar. A drill run against a Forgejo-only candidate fetches the GitHub installer, and if $REF exists only on Forgejo the fetch 404s and the leg dies before the assert.
  • drill/drill.sh:253-258 ref_sha resolves the recorded commit with
    git ls-remote "https://github.com/$1" — for both rig and box. A Forgejo-only ref records unresolved in drills/<version>.md, so the record cites no commit for the tree it drilled.

Consequence, stated plainly: after !114 merges, the release gate keeps proving the GitHub channel while the shipped installer has two. The failure mode is the one assert_installed_from (drill/drill.sh:140-161) was written to prevent — a record that looks like evidence for a combination that was never drilled.

Adjacent, same root, cheap to fix in the same pass:

  • README.md:19,21 — both headline install lines are raw.githubusercontent.com, and test/cli.sh:513-516,536 assert that spelling literally, so any doc change reds CI unless the assertion moves with it.
  • drill/drill.sh:250 cites install.sh:117-120 for the tags-outrank-branches precedence; !114 moves those lines.

Measured on this instance, 2026-07-29, anonymous: …/heavy-duty/rig/raw/branch/main/install.sh → 200; git ls-remote https://forgejo.heavyduty.builders/heavy-duty/rig resolves tags and heads anonymously.

Spec

The drill takes the same knob the installer takes, and records the forge it drilled.

  • RIG_HOST / BOX_HOST (defaults https://github.com) are read by the drill and threaded into (a) the installer fetch and (b) ref_sha, using !114's grammar: GitHub → raw.githubusercontent.com/<repo>/<ref>/install.sh; otherwise → <host>/<repo>/raw/branch/main/install.sh for the entrypoint and <host>/<repo> as the ls-remote origin.
  • The drill passes RIG_HOST through to install.sh's environment, so the installer's own candidate grammar decides the download — the drill must not build archive URLs of its own.
  • The record (drills/<version>.md) names the host for each pinned ref. unresolved stays reserved for a genuinely unresolvable ref, never for "I looked on the wrong forge".
  • No change to what the four legs assert. This is the instrument's plumbing, not its verdicts (#105's boundary).

Not in scope: whether GitHub or Forgejo is rig's canonical home (open product question on #111), and the INSTALLED_FROM format itself (#124 — if that lands first, the drill's assert_installed_from expectation moves with it).

Tasks

  • drill/drill.sh — read RIG_HOST / BOX_HOST, default GitHub; render the installer entrypoint per forge; pass RIG_HOST into the installer's env
  • ref_sha — take the host, ls-remote against it, keep tags-outrank-branches
  • emit_record — name the host beside each pinned ref
  • --rig-host / --box-host flags beside --rig-ref / --box-ref, and usage() lines for them
  • refresh the install.sh:117-120 line cite in ref_sha's comment
  • README.md:19,21 — document the Forgejo install line beside the GitHub one, and move test/cli.sh:513-516,536 in the same commit
  • changelog.d/<this issue>.md

Acceptance criteria

  • RIG_HOST=https://forgejo.heavyduty.builders drills a Forgejo-only rig ref end to end, with assert_installed_from passing
  • the emitted record names the host and a resolved 7-char SHA for every pinned ref drilled from Forgejo
  • no RIG_HOST / BOX_HOST set → every URL and every ls-remote origin is byte-identical to today's GitHub behaviour
  • a ref that exists on neither forge still fails loudly, naming what it tried — never unresolved plus a green leg
  • README.md and test/cli.sh's install-line assertions agree
  • shellcheck -x, bash test/cli.sh, bash test/drill.sh green

Test plan

  • test/drill.sh — extract the URL/ls-remote renderers with the suite's existing awk idiom and drive both forges, including the both-404 refusal; the record emitter asserted to carry the host
  • test/cli.sh — the README install lines assert both channels
  • Live, in a box: a real four-leg run is a release's drill, not CI's, so the acceptance run is manual and its log goes in the PR
  • Must fail: a Forgejo-only ref with RIG_HOST unset — the drill dies at the fetch, and must not reach a leg verdict

Dependencies

Blocked by #111 — the drill threads RIG_HOST into install.sh, which grows the knob there.

Related: #105 (the instrument), #107 (the next release needs a real record), #124 (INSTALLED_FROM gains a forge), #103 (README headline channel).

cc @andres — filing under your #111 comment 3664 exception. If you would rather this ride !114 instead of standing alone, say so and it can be closed into that scope; my read is that it is a separate deliverable (the drill is the release gate, not the install channel) and !114 is already at handoff.

Filed from the !114 review round (#111) as a **panel-spotted gap**, not through triage — hence `needs-triage`. It is the one site from #111's review that nobody filed: #123 took the `templates_archive_urls` comment, #124 took `INSTALLED_FROM`, #125 took `BOX_MANUAL`, and this one has no owner. ## Context !114 gives `install.sh` a `RIG_HOST` knob (default `https://github.com`) so rig can be installed from this Forgejo. The **drill** — rig's release-evidence instrument, and the gate `drill-recorded` enforces on a release PR — cannot exercise that channel, because it hardcodes GitHub in two places: - `drill/drill.sh:380-381` installs the candidate with `bash <(curl -fsSL "https://raw.githubusercontent.com/$REPO/$REF/install.sh")` — no `RIG_HOST`, no forge-aware raw grammar. A drill run against a Forgejo-only candidate fetches the *GitHub* installer, and if `$REF` exists only on Forgejo the fetch 404s and the leg dies before the assert. - `drill/drill.sh:253-258` `ref_sha` resolves the recorded commit with `git ls-remote "https://github.com/$1"` — for **both** rig and box. A Forgejo-only ref records `unresolved` in `drills/<version>.md`, so the record cites no commit for the tree it drilled. Consequence, stated plainly: after !114 merges, the release gate keeps proving the *GitHub* channel while the shipped installer has two. The failure mode is the one `assert_installed_from` (`drill/drill.sh:140-161`) was written to prevent — a record that looks like evidence for a combination that was never drilled. Adjacent, same root, cheap to fix in the same pass: - `README.md:19,21` — both headline install lines are `raw.githubusercontent.com`, and `test/cli.sh:513-516,536` assert that spelling literally, so any doc change reds CI unless the assertion moves with it. - `drill/drill.sh:250` cites `install.sh:117-120` for the tags-outrank-branches precedence; !114 moves those lines. Measured on this instance, 2026-07-29, anonymous: `…/heavy-duty/rig/raw/branch/main/install.sh` → 200; `git ls-remote https://forgejo.heavyduty.builders/heavy-duty/rig` resolves tags and heads anonymously. ## Spec The drill takes the same knob the installer takes, and records the forge it drilled. - `RIG_HOST` / `BOX_HOST` (defaults `https://github.com`) are read by the drill and threaded into (a) the installer fetch and (b) `ref_sha`, using !114's grammar: GitHub → `raw.githubusercontent.com/<repo>/<ref>/install.sh`; otherwise → `<host>/<repo>/raw/branch/main/install.sh` for the entrypoint and `<host>/<repo>` as the `ls-remote` origin. - The drill passes `RIG_HOST` through to `install.sh`'s environment, so the installer's own candidate grammar decides the download — the drill must not build archive URLs of its own. - The record (`drills/<version>.md`) names the host for each pinned ref. `unresolved` stays reserved for a genuinely unresolvable ref, never for "I looked on the wrong forge". - No change to what the four legs assert. This is the instrument's plumbing, not its verdicts (#105's boundary). Not in scope: whether GitHub or Forgejo is rig's canonical home (open product question on #111), and the `INSTALLED_FROM` format itself (#124 — if that lands first, the drill's `assert_installed_from` expectation moves with it). ## Tasks - [ ] `drill/drill.sh` — read `RIG_HOST` / `BOX_HOST`, default GitHub; render the installer entrypoint per forge; pass `RIG_HOST` into the installer's env - [ ] `ref_sha` — take the host, `ls-remote` against it, keep tags-outrank-branches - [ ] `emit_record` — name the host beside each pinned ref - [ ] `--rig-host` / `--box-host` flags beside `--rig-ref` / `--box-ref`, and `usage()` lines for them - [ ] refresh the `install.sh:117-120` line cite in `ref_sha`'s comment - [ ] `README.md:19,21` — document the Forgejo install line beside the GitHub one, and move `test/cli.sh:513-516,536` in the same commit - [ ] `changelog.d/<this issue>.md` ## Acceptance criteria - [ ] `RIG_HOST=https://forgejo.heavyduty.builders` drills a Forgejo-only rig ref end to end, with `assert_installed_from` passing - [ ] the emitted record names the host and a resolved 7-char SHA for every pinned ref drilled from Forgejo - [ ] no `RIG_HOST` / `BOX_HOST` set → every URL and every `ls-remote` origin is byte-identical to today's GitHub behaviour - [ ] a ref that exists on neither forge still fails loudly, naming what it tried — never `unresolved` plus a green leg - [ ] `README.md` and `test/cli.sh`'s install-line assertions agree - [ ] `shellcheck -x`, `bash test/cli.sh`, `bash test/drill.sh` green ## Test plan - `test/drill.sh` — extract the URL/`ls-remote` renderers with the suite's existing awk idiom and drive both forges, including the both-404 refusal; the record emitter asserted to carry the host - `test/cli.sh` — the README install lines assert both channels - Live, in a box: a real four-leg run is a release's drill, not CI's, so the acceptance run is manual and its log goes in the PR - Must fail: a Forgejo-only ref with `RIG_HOST` unset — the drill dies at the fetch, and must not reach a leg verdict ## Dependencies `Blocked by #111` — the drill threads `RIG_HOST` into `install.sh`, which grows the knob there. Related: #105 (the instrument), #107 (the next release needs a real record), #124 (`INSTALLED_FROM` gains a forge), #103 (README headline channel). cc @andres — filing under your #111 comment 3664 exception. If you would rather this ride !114 instead of standing alone, say so and it can be closed into that scope; my read is that it is a separate deliverable (the drill is the release gate, not the install channel) and !114 is already at handoff.
claude-bot-andresmgsl added the
enhancement
scope:installer
scope:drill
needs-triage
 labels 2026-07-29 22:37:34 +00:00
claude-bot-andresmgsl commented 2026-08-17 23:23:36 +00:00
Author
Member
Copy link

Triaged — ratified to contract, ready

Label events re-read before this write: needs-triage set at mint (2026-07-29), untouched since — this comment clears it.

Ratification: the body meets the contract as filed — deliverable-named title, spec with decisions (the drill takes RIG_HOST/BOX_HOST and threads them; it builds no archive URLs of its own; unresolved stays reserved for genuinely unresolvable refs), ordered tasks, verifiable acceptance criteria including the both-404 must-fail, and a test plan in the suite's existing idiom.

The one dependency, Blocked by #111, has landed: #111 is closed and install.sh carries the RIG_HOST knob on main (install.sh:40-44). No sweep runs on this instance to flip blocked→ready, so triage verifies the dependency by hand and sets ready directly. Note for the builder: #124 (INSTALLED_FROM gains a forge) is still open — the spec's provision that assert_installed_from's expectation moves with it remains live.

## Triaged — ratified to contract, `ready` Label events re-read before this write: `needs-triage` set at mint (2026-07-29), untouched since — this comment clears it. Ratification: the body meets the contract as filed — deliverable-named title, spec with decisions (the drill takes `RIG_HOST`/`BOX_HOST` and threads them; it builds no archive URLs of its own; `unresolved` stays reserved for genuinely unresolvable refs), ordered tasks, verifiable acceptance criteria including the both-404 must-fail, and a test plan in the suite's existing idiom. The one dependency, `Blocked by #111`, has landed: #111 is closed and `install.sh` carries the `RIG_HOST` knob on `main` (`install.sh:40-44`). No sweep runs on this instance to flip blocked→ready, so triage verifies the dependency by hand and sets **`ready`** directly. Note for the builder: #124 (`INSTALLED_FROM` gains a forge) is still open — the spec's provision that `assert_installed_from`'s expectation moves with it remains live.
claude-bot-andresmgsl added
ready
 and removed
needs-triage
 labels 2026-08-17 23:23:37 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
build/139-sbin-path-preflight
build/144-default-labels-option-b
build/144-ubuntu-latest-tooling
build/136-cli-hermetic
build/133-status-active-is-not-health
build/129-forgejo-runner-drill-leg
build/135-runner-cache-dir
build/131-readme-forgejo-install
build/111-install-channel-forge-agnostic
build/112-ceremony-uses-absolute
build/109-forgejo-ci-box
0.3.1
0.3.0
0.2.0
0.1.0
Labels
Clear labels   
attention

A demand is parked here for the assignee: pick up the thread, ack by removing this label

  
blocked

Waiting on another PR or issue to land first

  
blocker:ci-red

A check is failing — the agent owes a fix (not a rebase)

  
blocker:conflict

Does not merge — the branch conflicts and the agent owes a rebase

  
blocker:drill-pending

Release ceremony is correct but has no drill record yet

  
blocker:unrequested

Somebody still owes a verdict and nobody was asked for one

  
bug

Something isn't working

  
claimed

A builder owns it: assignee set, draft PR expected shortly

  
documentation

Improvements or additions to documentation

  
enhancement

New feature or request

  
epic

Organizes other issues via a dependency-ordered task list — builders never pick it

  
merge-next

Head of the merge queue — merge this one next (set by hand/agent, cleared here)

  
needs-ruling

A human decision is pending — question, options and a recommendation are in the comment

  
needs-triage

Did not come through triage — owes normalization or conversion to a discussion

  
offsite

Issue deliverable is a PR in another repository — claim clock paused

  
post-merge

Refs-linked PR merged; post-merge criteria remain and triage owns completion

  
ready

Triaged, spec complete, unblocked — a builder can start now and succeed

  
release

Release flow and version/packaging work

  
scope:bootstrap

bootstrap — hardening a pristine server into a node

  
scope:coolify

coolify-* — Coolify and backup install

  
scope:db

db.sh — dump/restore

  
scope:docs

README, CONTRIBUTING, docs/ — the prose contract

  
scope:drill

drill/ and drills/ — the harness, its legs and its records

  
scope:installer

install.sh — how rig lands on a machine

  
scope:labels

the labels workflow, the reconciler, labels.conf and labeler.yml

  
scope:platform

rig platform — machine facts and identity, converged or not

  
scope:runner

runner-* — GitHub runner lifecycle

  
scope:users

users-* — class model, apply/status, close-root

  
stale

No activity for 48h — needs a poke (sweep-managed)

  
state:addressing

All bots reviewed — coding agent owes the single reply + fixes

  
state:bots-reviewing

Waiting on the bot reviewers to finish the round

  
state:building

PR is a draft — the coding agent is still building

  
state:needs-human

No blockers, all bots approve — waiting on the human reviewer

No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:bootstrap
scope:coolify
scope:db
scope:docs
scope:drill
scope:installer
scope:labels
scope:platform
scope:runner
scope:users
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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: heavy-duty/rig#127
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?