CoreCI's ValidateShellCommand (internal/runner/validate.go) rejects
invoke: strings containing &|;`><$() — security measure to prevent
shell injection. The previous .coreci.yml jobs had inline invoke:
commands with || redirects and $(date) substitution, causing:
job "gitleaks" failed: shell command contains forbidden metacharacters
Fix: all complex logic moved to scripts/ci-run.sh. Each .coreci.yml job
uses invoke: "sh scripts/ci-run.sh <job-name>" — no metacharacters in
the invoke: string. The script itself can use any shell features
internally (CoreCI only validates the invoke: field, not what the script
does).
---ci---
project: orca
phase: 1
milestone: v0.16
status: execute
---/ci---
CoreCI's validate() rejects jobs with both plugin and invoke set
(mutually exclusive — pipeline.go:119). The previous commit used both
plugin: docker://golang:1.25.12 and invoke: on each job, causing:
Error: load config: validate: job "gosec": plugin and invoke are
mutually exclusive
Fix: remove all plugin: fields. Jobs run via the shell-isolated executor
which runs sh -c <invoke> directly. Go 1.25 is installed on the Gitea
Actions runner via actions/setup-go, so all Go commands work. Tool
installation via go install (gosec, govulncheck) and curl (gitleaks,
tea) works in the shell-isolated executor.
---ci---
project: orca
phase: 1
milestone: v0.16
status: execute
---/ci---
The embed build tag requires web/build (SvelteKit SPA) and bin/coreci-func
(Rust sidecar) — both are gitignored generated artifacts not present in
a shallow clone. coreci run only needs the CLI (no web UI), so building
without embed works: assets.go (!embed tag) returns ErrNoEmbeddedAssets
which is only referenced by the server's static asset serving, not by
the run command.
---ci---
project: orca
phase: 1
milestone: v0.16
status: execute
---/ci---
REQ-183: Fix .gitea/workflows/release.yml — the git clone of the private
coreci repo failed because the clone command had no credentials. The
actions/checkout@v4 step only injects auth for the orca repo. Fix: pass
GITEA_TOKEN env to the Install CoreCI step and embed it in the clone
URL (https://cloudinit-bot:${GITEA_TOKEN}@git.cloudinit.dev/...).
REQ-184: Rewrite .coreci.yml from the invalid pipelines:/steps:/image:/
commands: format to CoreCI's native jobs:/plugin:/invoke:/vars: format
with a proper DAG (needs:). CoreCI's Pipeline struct only recognizes
jobs:/services:/env: top-level keys — unknown fields are silently dropped
by yaml.Unmarshal, producing an empty Jobs map → zero jobs execute.
The rewrite:
- 8 jobs: go-vet → fan-out (verify-reqs, gosec, govulncheck, gitleaks)
→ build → test → release
- plugin: docker://golang:1.25.12 + invoke: on each job (container path
with shell-isolated fallback — Go is installed on the runner)
- GITEA_TOKEN via vars: with ${{ secrets.GITEA_TOKEN }} (resolved from
env via CoreCI's secret resolver os.Getenv fallback)
- CI_COMMIT_BRANCH (tag name on tag push) and CI_COMMIT_SHA for version
injection — no ${VAR} interpolation in YAML fields (shell expansion
only works inside invoke: via sh -c)
- No apk add (runner is ubuntu, not alpine — uses curl for tool downloads)
- Release job handles duplicate release (ship workflow creates release
first with title+body; coreci run attaches binary assets later via API
fallback if tea releases create fails)
- Release job verifies asset count ≥ 2 (REQ-097 gate C-21) with retry
Root cause: all 87 releases in repo history had zero binary assets
because coreci run never executed any jobs (empty Jobs map from the
invalid format) and the Gitea Actions workflow failed before reaching
coreci run (private repo clone had no credentials).
---ci---
project: orca
phase: 1
milestone: v0.16
status: execute
requirements:
covered: [183, 184]
partial: []
---/ci---
Establish milestone v0.16 to fix the root cause of releases shipping
with zero binary assets. v0.15 added a Gitea Actions workflow but it
never executed successfully due to two compounding bugs (documented in
REQUIREMENTS.md REQ-183, REQ-184). All 87 releases in the repo's
history have zero binary assets — this has never worked.
---ci---
project: orca
phase: 0
milestone: v0.16
status: specify
---/ci---
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---
Adversarial review of PLAN_v0.14.md across 9 axes. Verdict: RETHINK
(confidence 0.45). The research foundation is strong but the plan
diverges from it and from the codebase in load-bearing ways.
4 binding decisions (G-001..G-004):
- G-001: migration number 0009 (not 0007 — already taken by certs)
- G-002: omit :Z flag (contradicts CLARIFY D-258 + REQ-172)
- G-003: wire real mTLS now (scope expansion — plan has no such phase)
- G-004: P2 T6 must remove legacy systemd unit + binary on upgrade
12 binding conditions (C-50..C-61) + 14 phase challenges (PC-01..14).
1 escalation (E-001): G-003 mTLS direction undetermined in plan.
Key findings:
- F1.1: migration 0007 collision (BLOCKER)
- F1.2: certpaths.CAPath() does not exist (compile BLOCKER)
- F2.2: REQ-100 traefik-on-public-ip opt-out regressed by baked image
- F5.1: no v0.13 -> v0.14 upgrade path (BLOCKER)
- F7.2: podman pull violates R-001 offline-first
---ci---
status: grill
milestone: v0.14
binding-decisions:
- G-001: migration 0009_ingress_mode.sql (not 0007)
- G-002: omit :Z, use :ro on both mounts
- G-003: wire real mTLS now (scope expansion, plan must add phase)
- G-004: P2 T6 must remove legacy systemd unit + binary on upgrade
escalations:
- E-001: G-003 mTLS direction chosen but plan has no phase for it (conf 0.55)
verdict: rethink
confidence: 0.45
orca init now interactively prompts for remote host addresses and runs
ssh-copy-id automatically (password prompt passes through to the
operator). This makes orca init the single entry point — no manual
pre-staging of SSH keys required.
- Interactive: enter host addresses (one per line, empty line to finish)
- ssh-copy-id deploys the orca public key to each host
- Skipped in --json mode (non-interactive)
- Idempotent: re-running init can stage additional hosts
Also fixed: install.sh defaults to /usr/local/bin (on PATH for all users).
Non-root without sudo falls back to ~/.local/bin + auto-adds to .bashrc.
Root or writable /usr/local/bin: install there (no PATH edits needed).
Non-root without sudo: fall back to ~/.local/bin + auto-add to .bashrc.
This eliminates the 'NOTE: not on your PATH' message for the common case.
- createPVERole: use grep -qF + fallback to pveum role mod (was broken
by single-quote-in-grep pattern: grep -q '^'OrcaOperator'')
- createPVEUser: same idempotency fix (grep -qF + fallback to mod)
- orca init: prints ssh-copy-id instructions with the orca public key
path after generating the SSH keypair
- docs/uat.md: removed manual pre-staging (ssh-keygen, ssh-copy-id
with operator key, host-key fingerprint pinning). orca init handles
key generation; node join uses the orca key by default; TOFU is
automatic. Updated node join examples to not pass --ssh-key or
--host-key-fingerprint.
---ci---
project: orca
status: fix
---/ci---
install.sh:
- find_asset_url now matches by asset NAME (python3 JSON parse), not
URL path — Gitea attachment URLs are opaque UUIDs that don't contain
the tarball name. This was the root cause of the v0.12.18 install
failure (asset existed but install.sh couldn't find it).
- find_asset_in_releases walks recent releases by asset name and
returns both URL + version for the fallback walk.
- Handles 404 (tag without release) gracefully via fallback walk.
Dockerfile:
- golang:1.25 -> golang:1.25.12 (go.mod requires 1.25.12; the Docker
image was using patch 0, causing `go mod download` to fail with
"go.mod requires go >= 1.25.12 (running go 1.25.10)")
coreci.yml:
- All golang:1.25 images -> golang:1.25.12
- Release pipeline: add SHA256SUMS generation (sha256sum tarball)
- Release pipeline: attach SHA256SUMS alongside tarball
- Release pipeline: verify assets are actually attached after
tea releases create (REQ-097 gate C-21); auto-attach via API if
tea failed silently
release.sh:
- Add SHA256SUMS generation (sha256sum tarball > SHA256SUMS)
---ci---
project: orca
milestone: v0.12.18
phase: release-fix
status: complete
---/ci---
- deployRemote branches on runtime: pve-ct/pve-vm on proxmox nodes
invoke runtime.Registry.Prepare+Start (creates LXC/VM via SSH);
process runtime on linux nodes uses systemd emitter; process on
proxmox is rejected with clear error
- deployRemote emits Traefik dynamic config when spec has ports
(TraefikEmitter.Render + SSH-push to /etc/traefik/dynamic/)
- model.Job: added Node field so job list --json reports deployed node
- job run remote case: inserts model.Job + alloc_history after
deployRemote succeeds (job list and job stop now work for remote)
- --target name lookup: legacy dispatcher tries NodeID match
- job list UX: short 8-char IDs, NODE column, conditional EXIT (- for
non-terminal statuses)
- emitter/traefik.go: directory provider (was single file), pve-ct/pve-vm
registered in RegisterTraefik
- runtime/pve.go: shellQuote for image, idempotent create check
---ci---
project: orca
milestone: v0.12.18
phase: C
status: complete
requirements:
covered: [166]
---/ci---
Jon Chery