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---
---ci---
project: orca
phase: 3
milestone: v0.3
status: complete
requirements:
covered: [REQ-022, REQ-030, REQ-032]
partial: []
---/ci---
v0.3 milestone merged to main. Includes all v0.2 work (P08-P10) that
was previously on the milestone branch but not yet merged to main, plus
the v0.3 completion work (iter.Seq streaming + doctor network/db).
v0.2 phases included: P08 (mTLS), P09 (scheduling), P10 (security scan).
v0.3 phases: P0 (pre-execution), P1 (iter.Seq streaming), P2 (doctor),
P3 (final review+ship).
Total: 40 requirements, all complete. No new go.mod dependencies.
Full test suite passes under -race. gofmt + go vet clean.
- Fast-forward merge of phase/07-v0.1-backfill into milestone/v0.1-initial
- Annotated tag v0.1.7 created at dc67522
- Gitea release v0.1.7 published with orca-v0.1.7-linux-amd64.tar.gz
- Fix -> typo in release.sh notes block
(unbound variable under set -u; surfaced on first end-to-end run
of release.sh for v0.1.7). Patch is minimal and contained to the
release-notes echo line.
The v0.1 milestone COMPLETE commit (d76ff84) was tagged v0.2.0 and the
per-phase tags v0.1.1..v0.1.6 were created, but the standing rule
'every phase tag produces a Gitea release' was only codified in P06
(RELEASE_POLICY.md) and never applied retroactively.
This commit adds scripts/backfill_releases.sh, an idempotent helper that:
- iterates over v0.1.1..v0.1.6 and v0.2.0
- skips tags that already have a release
- builds the orca binary from the milestone branch HEAD (which includes
the post-COMPLETE entry-point fix and workflow-block commits)
- injects the historical version via -ldflags
- packages a per-tag tarball (orca-<tag>-<os>-<arch>.tar.gz)
- creates a Gitea release with the tarball as an asset, and release
notes that include the phase summary and a v0.2.0 milestone recap
After backfill, the v0.1 milestone is fully released end-to-end and the
discipline carries forward into v0.2.
---ci---
project: orca
phase: 7
milestone: v0.1
status: execute
version: v0.1.7
requirements:
covered: [REQ-007]
partial: []
---/ci---
Jon Chery
cloudinit-bot