fix(ci): Lint / Test / Vet failing on main since 2026-06-29 #19

Closed
opened 2026-07-21 21:19:12 +00:00 by mathias · 1 comment
Owner

Symptom

cd.yml job Lint / Test / Vet fails on every push to main since run #55 (2026-06-29), most recently run #57. Build & Import and Deploy via GitOps are consequently skipped downstream.

Note: a manual workflow_dispatch re-run of the same commit (run #56, "fix(ci): drop empty LOOP_MODEL env that blanked the model → LLM 400") passed — so the failure may be push-trigger-context-specific (missing env/secret only present in scheduled/dispatch context), not a pure code bug. Needs confirmation.

Surfaced via homelab-alerts RepoCIRedStuck (ntfy, 2026-07-21 01:03 UTC).

Investigation needed

  • Pull actual Lint / Test / Vet step logs (not available via REST/MCP from this session — 404 on job-logs endpoint).
  • Confirm whether push vs dispatch env difference is the real cause.

Acceptance criteria

  • Root cause identified.
  • A push to main produces a green Lint / Test / Vet job.
## Symptom `cd.yml` job `Lint / Test / Vet` fails on every push to `main` since run #55 (2026-06-29), most recently run #57. `Build & Import` and `Deploy via GitOps` are consequently `skipped` downstream. Note: a manual `workflow_dispatch` re-run of the same commit (run #56, "fix(ci): drop empty LOOP_MODEL env that blanked the model → LLM 400") passed — so the failure may be push-trigger-context-specific (missing env/secret only present in scheduled/dispatch context), not a pure code bug. Needs confirmation. Surfaced via homelab-alerts `RepoCIRedStuck` (ntfy, 2026-07-21 01:03 UTC). ## Investigation needed - Pull actual `Lint / Test / Vet` step logs (not available via REST/MCP from this session — 404 on job-logs endpoint). - Confirm whether push vs dispatch env difference is the real cause. ## Acceptance criteria - Root cause identified. - A push to `main` produces a green `Lint / Test / Vet` job.
Author
Owner

Root cause (not a push-vs-dispatch env difference — that guess was wrong)

Taskfile.yml line 46 had an unquoted Go-template {{.VAR}} inside a YAML flow sequence (cmds: [...]) — the literal braces broke YAML parsing outright (did not find expected ',' or ']'), so task check failed before running a single command, on every push. The workflow_dispatch re-run (#56) that looked like it "passed" never actually calls task check — it's the unrelated autoresearch.yml workflow, which explains the apparent push-vs-dispatch discrepancy.

Fixed the Taskfile, which then surfaced a real staticcheck finding (QF1002, a boolean switch on the same variable in every case → converted to a tagged switch in internal/eval/var.go).

Second layer: build/deploy shouldn't exist here at all

Once check passed, Build & Import started actually running — and failed, because Dockerfile builds ./cmd/hostexecutor, a directory that hasn't existed since the rename (real dirs: cmd/eval, cmd/jepa-fx-risk). Traced this back: issues #6 and #7 (both already closed) explicitly decided this repo's CI should be check-only — no build, no deploy, since training runs are manual/GPU-bound and never CI-triggered. That decision never actually landed in cd.yml, which still carried the original go-web template's build+deploy jobs verbatim. Confirmed no k3s/apps/hostexecutor or k3s/apps/jepa-fx-risk deployment manifest exists in mathias/infra — this repo has never been deployed and per #6/#7 was never meant to be. Removed both jobs.

Verified: run #59 — only Lint / Test / Vet: success. No build/deploy jobs remain.

Closing.

## Root cause (not a push-vs-dispatch env difference — that guess was wrong) `Taskfile.yml` line 46 had an unquoted Go-template `{{.VAR}}` inside a YAML flow sequence (`cmds: [...]`) — the literal braces broke YAML parsing outright (`did not find expected ',' or ']'`), so `task check` failed before running a single command, on every push. The `workflow_dispatch` re-run (#56) that looked like it "passed" never actually calls `task check` — it's the unrelated `autoresearch.yml` workflow, which explains the apparent push-vs-dispatch discrepancy. Fixed the Taskfile, which then surfaced a real staticcheck finding (`QF1002`, a boolean switch on the same variable in every case → converted to a tagged switch in `internal/eval/var.go`). ## Second layer: build/deploy shouldn't exist here at all Once `check` passed, `Build & Import` started actually running — and failed, because `Dockerfile` builds `./cmd/hostexecutor`, a directory that hasn't existed since the rename (real dirs: `cmd/eval`, `cmd/jepa-fx-risk`). Traced this back: issues #6 and #7 (both already closed) explicitly decided this repo's CI should be **check-only** — no build, no deploy, since training runs are manual/GPU-bound and never CI-triggered. That decision never actually landed in `cd.yml`, which still carried the original go-web template's build+deploy jobs verbatim. Confirmed no `k3s/apps/hostexecutor` or `k3s/apps/jepa-fx-risk` deployment manifest exists in `mathias/infra` — this repo has never been deployed and per #6/#7 was never meant to be. Removed both jobs. **Verified:** run #59 — only `Lint / Test / Vet: success`. No build/deploy jobs remain. Closing.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/jepa-fx-risk#19