The upload succeeded (assets 107+108 created with correct sizes), but
the /releases/tags/{tag} endpoint returned 0 assets due to a Gitea
caching/replication delay. The /releases/{id}/assets endpoint correctly
shows 2 assets. Fix: verify via the direct assets endpoint.
THE RELEASE PIPELINE WORKS — v0.15.1 has 2 binary assets:
- orca-v0.15.1-linux-amd64.tar.gz (7.6MB)
- SHA256SUMS (98 bytes)
---ci---
project: orca
phase: 1
milestone: v0.16
status: execute
---/ci---
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---
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---
Jon Chery