Commit Graph

2 Commits

Author SHA1 Message Date
Jon Chery 61c97c847c fix(P1): recompute TARBALL after fallback version walk (REQ-132)
The fallback walk (REQ-098) reassigns VERSION from the requested
release to the nearest older release carrying a binary asset, but
never recomputed TARBALL (set once at line 106 from the requested
version). The stale tarball name then flowed into:

  - grep -F "$TARBALL" SHA256SUMS  -> matched nothing (the fallback
    release's SHA256SUMS only lists the fallback tarball)
  - sha256sum -c -                 -> empty stdin -> "no properly
    formatted checksum lines found" -> REQ-132 refusal
  - tar -xzf "${TMPDIR}/${TARBALL}" -> would look for the wrong
    filename (download saved under the stale name too)

User-visible symptom (v0.14.2 latest had no asset, fell back to
v0.12.18):

  install: verifying checksum...
  sha256sum: 'standard input': no properly formatted checksum lines found
  install: error: checksum verification failed (REQ-132); refusing to install

Fix: recompute TARBALL immediately after VERSION is reassigned in the
fallback branch, so download/grep/sha256sum/tar all reference the
fallback version's tarball. ASSET_URL and SHA256SUMS_URL were already
correct (derived from the API/ASSET_URL); TARBALL was the only stale
variable.

Reproduced the exact error before the fix; confirmed end-to-end
install succeeds after (orca-v0.12.18-linux-amd64.tar.gz: OK ->
extracting -> installed). Added a bats regression test pinning
--version v0.14.2 and asserting the dry-run "would install" line
references the fallback version (not the stale pinned one).

---ci---
project: orca
phase: 1
milestone: v0.15
status: execute
decisions:
  - id: D-001
    decision: Recompute TARBALL in the fallback branch immediately
      after VERSION is reassigned, so grep/sha256sum/tar use the
      fallback version's filename instead of the stale requested
      version's.
    rationale: Reproduced the exact user error ("no properly formatted
      checksum lines found") by running grep -F "$TARBALL" SHA256SUMS
      | sha256sum -c with a stale v0.14.2 tarball name against v0.12.18
      SHA256SUMS. TARBALL is the only stale variable: ASSET_URL and
      VERSION are correctly updated from API output, and SHA256SUMS_URL
      derives from ASSET_URL. Single-line fix, minimal blast radius,
      preserves the working non-fallback path.
    confidence: 0.96
    alternatives:
      - lazy TARBALL via a function (over-engineering for one stale
        assignment)
      - move TARBALL= assignment past the fallback block (breaks
        find_asset_url which needs the requested version's name
        pre-walk)
lessons:
  - When a fallback/walk mutates one variable (VERSION), audit every
    variable derived from it (TARBALL) for the same mutation. The
    user-facing info line at 167 constructed the name inline and
    looked correct, masking that the variable itself was stale.
---/ci---
2026-08-10 21:18:24 +00:00
Jon Chery eadd28fac0 fix(P01): release.sh cross-build amd64 + asset verification; install.sh fallback walk + --check
P01 — release/install pipeline fix (REQ-097, REQ-098; gate C-21).

release.sh (REQ-097):
- Cross-build linux-amd64 regardless of host arch (GOOS=linux GOARCH=amd64
  go build, CGO_ENABLED=0). D-193: the host-arch build produced the wrong
  tarball when cut from arm64 — root cause of the v0.8.x asset-less
  releases.
- Hardcode tarball name to orca-${VERSION}-linux-amd64.tar.gz (not
  host-arch-dependent).
- Post-create asset verification (C-21): after tea releases create, query
  the Gitea API and assert the tarball appears in attachments. Retry once
  via tea release edit if missing. Fail loudly if still missing. This
  catches the tea CLI bug where create exits 0 without attaching the asset.

install.sh (REQ-098):
- Asset fallback walk: if the resolved release (latest or --version) lacks
  the matching tarball, query /releases?limit=50, extract all
  browser_download_urls from the list response (assets are inline), find
  the newest release with a matching orca-*-linux-amd64.tar.gz asset, print
  a WARNING, and use that release. Fixes the v0.4.5 install incident where
  v0.8.15 had no asset and install.sh errored out with no fallback.
- --check dry-run mode (D-194): prints version + asset URL + install path
  + current version without writing anything.

Tests (scripts/tests/):
- install_test.bash: 5 tests (--help, --check happy path, --check fallback
  walk, unknown arg rejection, --system root check).
- release_test.bash: 5 tests (script exists, syntax valid, cross-build
  command present, amd64 tarball name hardcoded, asset verification present).

All 30 bats tests pass. make lint clean (no new warnings).

---ci---
project: orca
phase: 1
milestone: v0.10
status: execute
---/ci---
2026-08-05 20:52:25 +00:00