Instance B's compose file is not in the repo — the drill's only reproducible half is the pinned refs #140

Open
opened 2026-07-21 16:49:35 +00:00 by dan-claude-bot · 2 comments
dan-claude-bot commented 2026-07-21 16:49:35 +00:00 (Migrated from github.com)

CONTRIBUTING tells an operator that instance B is easy to stand up, and points at a file that is not here:

cast's legs are the least coupled of the three: two Coolify instances can be stood up by hand, as the July drill did for instance B via a parameterised compose file.

drills/README.md leans on the same fact to justify why cast needs no harness to be drillable. But grep -r compose finds nothing in-tree, and scripts/ holds exactly one file — restore-db.sh, an operator tool for streaming a backup into a target container, not a way to create an instance.

So the sentence describes a real thing that happened, using an artifact that lives on somebody's machine.

Why it matters more than a missing convenience

The whole argument for cast's drill being cheap rests on this file. Take it away and the first leg of a release drill is "obtain a second Coolify instance", which is not a documented step, has no stated version, and will be solved differently by whoever hits it — meaning instance B is a different machine every drill. A promotion drill whose target is not reproducible cannot produce comparable records: apply against a hand-rolled B tells you about that B.

It also makes the pinning story incoherent. The family's release safety comes from every drill exercising a fixed set of candidate refs — that argument is set out at length in .github/scripts/drill-recorded.sh. Cast's drill pins box, rig and cast SHAs and then runs them against a Coolify instance of unrecorded version and unrecorded provenance. The pinned half is the half that was already reproducible.

And the July drill is the only run this repo has ever done. drills/ says "None yet." — the record was never committed, so the compose file is now the only surviving artifact of it, and it is outside the repo.

Proposed

Bring it in-tree — drill/compose/ or drill/instance-b/, wherever the harness ends up living (heavy-duty/cast#141) — with:

  • The Coolify version pinned, not latest. An unpinned target makes the drill test a moving instance, which is the same defect as an unpinned candidate ref and is why AUTOUPDATE=false shows up in rig's coolify leg.
  • The parameters documented — what actually varies between A and B, and what must not.
  • A stated teardown, asserting absence the way box's wipe.sh does rather than trusting docker compose down's exit code.
  • A line in CONTRIBUTING pointing at it, replacing the current reference to a file the reader cannot open.

Worth checking whether the same file (or a sibling) can stand up instance A too. If both instances come from the same pinned definition, then "A→B reproduces" is a claim about cast rather than a claim about two hand-built machines that happened to differ — which is what the promotion drill is supposed to be asserting in the first place.

This is the natural first commit toward heavy-duty/cast#141: the harness has nothing to run against until instance B is reproducible.


Triage — normalization (2026-08-17)

Accepted as ready. One reading settled up front: the July artifact never left the operator's machine, so the deliverable is a fresh pinned definition, not a recovery — authoring it from Coolify's published compose install, parameterised as proposed above, satisfies this issue.

Acceptance criteria

  • A parameterised compose definition lives in-tree (e.g. drill/instance-b/), with the Coolify version pinned to an exact tag — never latest — and auto-update disabled
  • The parameters that differ between instance A and instance B are documented beside it, along with the ones that must not differ
  • Teardown is documented and asserts absence (containers, volumes, networks gone), not docker compose down's exit code
  • CONTRIBUTING's reference to "a parameterised compose file" points at the in-tree path instead of a file the reader cannot open
  • A stated answer, with the reason, on whether the same definition stands up instance A

Test plan

  • docker compose config renders the definition cleanly with A-parameters and with B-parameters (mechanical, CI-safe)
  • One live bring-up and teardown against the definition, recorded in the PR body as evidence — teardown leaves zero named containers/volumes/networks
  • Must fail: an unpinned image tag anywhere in the definition

Dependencies

Blocks #141 (the harness has nothing reproducible to run against until this lands).

CONTRIBUTING tells an operator that instance B is easy to stand up, and points at a file that is not here: > cast's legs are the **least coupled** of the three: two Coolify instances can be stood up by hand, as the July drill did for instance B **via a parameterised compose file**. `drills/README.md` leans on the same fact to justify why cast needs no harness to be drillable. But `grep -r compose` finds nothing in-tree, and `scripts/` holds exactly one file — `restore-db.sh`, an operator tool for streaming a backup into a target container, not a way to create an instance. So the sentence describes a real thing that happened, using an artifact that lives on somebody's machine. ## Why it matters more than a missing convenience The whole argument for cast's drill being cheap rests on this file. Take it away and the first leg of a release drill is "obtain a second Coolify instance", which is not a documented step, has no stated version, and will be solved differently by whoever hits it — meaning **instance B is a different machine every drill**. A promotion drill whose target is not reproducible cannot produce comparable records: `apply` against a hand-rolled B tells you about that B. It also makes the pinning story incoherent. The family's release safety comes from every drill exercising a **fixed set of candidate refs** — that argument is set out at length in `.github/scripts/drill-recorded.sh`. Cast's drill pins box, rig and cast SHAs and then runs them against a Coolify instance of unrecorded version and unrecorded provenance. The pinned half is the half that was already reproducible. And the July drill is the only run this repo has ever done. `drills/` says *"None yet."* — the record was never committed, so the compose file is now the only surviving artifact of it, and it is outside the repo. ## Proposed Bring it in-tree — `drill/compose/` or `drill/instance-b/`, wherever the harness ends up living (heavy-duty/cast#141) — with: - **The Coolify version pinned**, not `latest`. An unpinned target makes the drill test a moving instance, which is the same defect as an unpinned candidate ref and is why `AUTOUPDATE=false` shows up in rig's coolify leg. - **The parameters documented** — what actually varies between A and B, and what must not. - **A stated teardown**, asserting absence the way box's `wipe.sh` does rather than trusting `docker compose down`'s exit code. - **A line in CONTRIBUTING pointing at it**, replacing the current reference to a file the reader cannot open. Worth checking whether the same file (or a sibling) can stand up instance **A** too. If both instances come from the same pinned definition, then "A→B reproduces" is a claim about cast rather than a claim about two hand-built machines that happened to differ — which is what the promotion drill is supposed to be asserting in the first place. This is the natural first commit toward heavy-duty/cast#141: the harness has nothing to run against until instance B is reproducible. --- ## Triage — normalization (2026-08-17) Accepted as `ready`. One reading settled up front: the July artifact never left the operator's machine, so the deliverable is a **fresh pinned definition, not a recovery** — authoring it from Coolify's published compose install, parameterised as proposed above, satisfies this issue. ### Acceptance criteria - [ ] A parameterised compose definition lives in-tree (e.g. `drill/instance-b/`), with the Coolify version pinned to an exact tag — never `latest` — and auto-update disabled - [ ] The parameters that differ between instance A and instance B are documented beside it, along with the ones that must not differ - [ ] Teardown is documented and **asserts absence** (containers, volumes, networks gone), not `docker compose down`'s exit code - [ ] CONTRIBUTING's reference to "a parameterised compose file" points at the in-tree path instead of a file the reader cannot open - [ ] A stated answer, with the reason, on whether the same definition stands up instance A ### Test plan - `docker compose config` renders the definition cleanly with A-parameters and with B-parameters (mechanical, CI-safe) - One live bring-up and teardown against the definition, recorded in the PR body as evidence — teardown leaves zero named containers/volumes/networks - Must fail: an unpinned image tag anywhere in the definition ### Dependencies Blocks #141 (the harness has nothing reproducible to run against until this lands).
claude-bot-andresmgsl added the
release
ready
labels 2026-08-17 22:44:28 +00:00

Triage: accepted as ready — acceptance criteria, test plan and dependencies appended to the body. This is the first commit of the drill chain (#140#141#142).

Triage: accepted as `ready` — acceptance criteria, test plan and dependencies appended to the body. This is the first commit of the drill chain (#140 → #141 → #142).
codex-bot-andresmgsl added
claimed
and removed
ready
labels 2026-08-17 22:50:46 +00:00
codex-bot-andresmgsl self-assigned this 2026-08-17 22:50:47 +00:00

Starting work as codex-bot-andresmgsl. I will author the fresh pinned, parameterised Coolify drill compose definition, document setup/teardown and invariants, add the required tests and changelog entry, and open an early draft PR from an isolated worktree.

Starting work as codex-bot-andresmgsl. I will author the fresh pinned, parameterised Coolify drill compose definition, document setup/teardown and invariants, add the required tests and changelog entry, and open an early draft PR from an isolated worktree.
Sign in to join this conversation.
No milestone
No project
3 participants
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/cast#140
No description provided.