Commit Graph

2 Commits

Author SHA1 Message Date
Jon Chery 5af2b1d660 fix(P1): fix bash substring in ci-release.sh — dash doesn't support ${var:0:12}
Release / ci (push) Failing after 7m36s
Release / container-orca (push) Has been skipped
Release / container-traefik (push) Has been skipped
The Gitea Actions runner uses dash as /bin/sh. ${GIT_COMMIT:0:12} is
bash-only substring substitution. dash gives 'Bad substitution' (exit 1).

Fix: use $(echo "$GIT_COMMIT" | cut -c1-12) instead.

The coreci pipeline (build+test) SUCCEEDED in the last run — the only
failure was this shell compatibility issue in the release step.

---ci---
project: orca
phase: 1
milestone: v0.16
status: execute
---/ci---
2026-08-12 22:52:53 +00:00
Jon Chery df3f980fa0 fix(P1): move release to Gitea Actions step — CoreCI disk full issue
Release / ci (push) Failing after 5m54s
Release / container-orca (push) Has been skipped
Release / container-traefik (push) Has been skipped
CoreCI's SQLite logging fills the runner's disk during go test -race,
causing the release job to fail when writing the tarball (3-second
failure). The release job ran inside CoreCI's shell-isolated executor
which shares the same disk as CoreCI's SQLite DB.

Fix: move the release logic (build tarball + upload to Gitea) to a
separate Gitea Actions step that runs AFTER coreci run completes.
This step runs in the Gitea Actions runner directly (full env, no
CoreCI disk constraints). The .coreci.yml now only has build→test
jobs. The release is handled by scripts/ci-release.sh called from the
Gitea Actions workflow.

Architecture:
  Gitea Actions ci job:
    1. Checkout + Set up Go + Install CoreCI
    2. coreci run (executes .coreci.yml: build → test)
    3. sh scripts/ci-release.sh (build tarball + upload to Gitea API)

---ci---
project: orca
phase: 1
milestone: v0.16
status: execute
---/ci---
2026-08-12 22:36:56 +00:00