AuWoMe/Drift
2
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

CI workflow: all runs failing or cancelling since repo creation #7

New issue
Closed
opened 2026-09-11 02:54:58 +00:00 by Mark · 3 comments
Mark commented 2026-09-11 02:54:58 +00:00
Owner
Copy link

Symptom

The CI workflow .forgejo/workflows/ci.yml is failing or getting cancelled for every push to main. The flow uses actions/checkout@v4 and actions/setup-node@v4 — i.e. GitHub-hosted action references — and there is no working Forgejo-native mirror available in this Forgejo instance.

Evidence (Vikunja pilot card #4 / 2026-09-10 scan)

  • Run #244 — Update documentation with API key auth and new endpoints — status cancelled
  • Run #256 — security: add proper authentication with password hashing — status cancelled
  • Run #295 — feat: add tags for organizing projects — status cancelled
  • Run #372 — feat: add project relationships, tags, and test infrastructure — status cancelled
  • Run #2358 — fix: convert GitHub action URLs to Forgejo-native mirror — status failure
  • Run #2523 — CI — status failure
  • Run #2674 — Revert: use original action short names (git.forgejo.org doesn't resolve) — status failure

API returns 7 runs total on this repo, all in failure or cancelled. Job-step-logs endpoint /api/v1/repos/AuWoMe/Drift/actions/runs/<id>/jobs returns 404 — opaque-failure shape documented in diagnose-forgejo-actions. Steps shipped zero log output.

Attempted fixes (commits on main)

Mark already tried two remedies:

  1. ec48a65d — fix: convert GitHub action URLs to Forgejo-native mirror (used fully-qualified https://data.forgejo.org/... URLs).
  2. 2be36410 — Revert: use original action short names (git.forgejo.org doesn't resolve) (reverted to actions/checkout@v4 etc.).

Runs after both commits still fail/cancel — the runner cannot resolve those JS actions at all.

Diagnosis

Pattern matches the actions/checkout@v4 / third-party-action not cached failure mode from diagnose-forgejo-actions/SKILL.md:

A third-party action (e.g. codecov/codecov-action@v3) is not mirrored in the Forgejo local action cache (data.forgejo.org). The runner resolves all action dependencies during "Set up job" before any steps run. Fix: Replace the third-party action with one that IS cached (e.g. actions/upload-artifact@v3 instead of codecov/codecov-action@v3), or remove it entirely. Check raw logs for Unable to clone https://data.forgejo.org/... to identify the missing action.

The jobs endpoint returns 404, so the underlying action-resolution failure can only be confirmed by expanding the "Set up job" step in the Actions web UI.

Proposed work

Rewrite ci.yml so all uses: references resolve via the locally cached mirror or move to plain shell steps / a container:-based runner that doesn't need to fetch external JS actions. Likely candidates:

  • Drop actions/setup-node@v4 — preinstall Node 20 in a container: directive on the job (e.g. container: catthehacker/ubuntu:act-22.04).
  • Replace actions/checkout@v4 with a run: step that does apt-get install -y git && git clone ... (or pin checkout to a Forgejo-cached mirror tag).
  • Keep cache: 'npm' only after setup-node resolves; otherwise rely on npm ci with no cache.

Workflow file lives at .forgejo/workflows/ci.yml (only branch: main).

Acceptance criteria

  • A push to main produces a Forgejo Actions run that ends in success (or completed with at least one green step).
  • The CI steps (npm ci, npm run check, npm run build) all reach the post-step container cleanly.
  • Per-run logs are retrievable via GET /api/v1/repos/AuWoMe/Drift/actions/runs/<id>/jobs (i.e. the jobs endpoint stops 404-ing — a signal that log persistence works again on this Forgejo v13.0.4 instance).

Source: Vikunja task #192 (forgejo-bridge project) — pilot card for the 2026-09-10 forgejo-ci-failures scan.

## Symptom The CI workflow `.forgejo/workflows/ci.yml` is failing or getting cancelled for every push to `main`. The flow uses `actions/checkout@v4` and `actions/setup-node@v4` — i.e. GitHub-hosted action references — and there is no working Forgejo-native mirror available in this Forgejo instance. ### Evidence (Vikunja pilot card #4 / 2026-09-10 scan) - Run #244 — *Update documentation with API key auth and new endpoints* — status `cancelled` - Run #256 — *security: add proper authentication with password hashing* — status `cancelled` - Run #295 — *feat: add tags for organizing projects* — status `cancelled` - Run #372 — *feat: add project relationships, tags, and test infrastructure* — status `cancelled` - Run #2358 — *fix: convert GitHub action URLs to Forgejo-native mirror* — status `failure` - Run #2523 — *CI* — status `failure` - Run #2674 — *Revert: use original action short names (git.forgejo.org doesn't resolve)* — status `failure` API returns 7 runs total on this repo, all in `failure` or `cancelled`. Job-step-logs endpoint `/api/v1/repos/AuWoMe/Drift/actions/runs/<id>/jobs` returns 404 — opaque-failure shape documented in `diagnose-forgejo-actions`. Steps shipped zero log output. ## Attempted fixes (commits on `main`) Mark already tried two remedies: 1. `ec48a65d` — `fix: convert GitHub action URLs to Forgejo-native mirror` (used fully-qualified `https://data.forgejo.org/...` URLs). 2. `2be36410` — `Revert: use original action short names (git.forgejo.org doesn't resolve)` (reverted to `actions/checkout@v4` etc.). Runs after both commits still fail/cancel — the runner cannot resolve those JS actions at all. ## Diagnosis Pattern matches the **`actions/checkout@v4` / third-party-action not cached** failure mode from `diagnose-forgejo-actions/SKILL.md`: > A third-party action (e.g. codecov/codecov-action@v3) is not mirrored in the Forgejo local action cache (`data.forgejo.org`). The runner resolves all action dependencies during "Set up job" before any steps run. **Fix:** Replace the third-party action with one that IS cached (e.g. `actions/upload-artifact@v3` instead of `codecov/codecov-action@v3`), or remove it entirely. Check raw logs for `Unable to clone https://data.forgejo.org/...` to identify the missing action. The jobs endpoint returns 404, so the underlying action-resolution failure can only be confirmed by expanding the "Set up job" step in the Actions web UI. ## Proposed work Rewrite `ci.yml` so all `uses:` references resolve via the locally cached mirror or move to plain shell steps / a `container:`-based runner that doesn't need to fetch external JS actions. Likely candidates: - Drop `actions/setup-node@v4` — preinstall Node 20 in a `container:` directive on the job (e.g. `container: catthehacker/ubuntu:act-22.04`). - Replace `actions/checkout@v4` with a `run:` step that does `apt-get install -y git && git clone ...` (or pin checkout to a Forgejo-cached mirror tag). - Keep `cache: 'npm'` only after `setup-node` resolves; otherwise rely on `npm ci` with no cache. Workflow file lives at `.forgejo/workflows/ci.yml` (only branch: `main`). ## Acceptance criteria - A push to `main` produces a Forgejo Actions run that ends in `success` (or `completed` with at least one green step). - The CI steps (`npm ci`, `npm run check`, `npm run build`) all reach the post-step container cleanly. - Per-run logs are retrievable via `GET /api/v1/repos/AuWoMe/Drift/actions/runs/<id>/jobs` (i.e. the jobs endpoint stops 404-ing — a signal that log persistence works again on this Forgejo v13.0.4 instance). Source: Vikunja task #192 (forgejo-bridge project) — pilot card for the 2026-09-10 forgejo-ci-failures scan.
Mark commented 2026-09-11 05:06:57 +00:00
Author
Owner
Copy link

Automated runner (kilo-gsd-runner) could not launch on this issue. No code was changed.

Blocker: this repo has no pre-dispatch gate at .gsd/gates/pre-dispatch.sh.

cd /home/b/Projects/Drift && bash .gsd/gates/pre-dispatch.sh 7
bash: .gsd/gates/pre-dispatch.sh: No such file or directory
GATE_EXIT=127

The runner shells this gate unconditionally between its Plan and Implement phases.
A missing file returns exit 127, which is recorded as a gate FAILURE (not "no gate
configured") and routed to the mechanical bugfix agent, which then scaffolds a
bespoke gate and burns its retry budget. Launching into that is worse than stopping,
so the run was not started.

Every other precondition is green:

  • worktree /home/b/Projects/Drift clean, HEAD 2be3641 on main
  • no live runner process or tmux session for this issue
  • no commit on origin/main referencing #7
  • issue open, labels bug / triage-approved

Fixed in passing: the repo had no in-progress label defined, which would have
made the runner's claim step fail with a 422. It now exists (id 1182), so that will
not block the next attempt.

Operator remedy (.gsd/ is gitignored, operator-provisioned tooling state — the
launcher is not permitted to create it):

install -D -m 755 /home/b/Projects/infrastructure/.gsd/gates/pre-dispatch.sh \
  /home/b/Projects/Drift/.gsd/gates/pre-dispatch.sh

Canonical gate md5=71f169a29925057bece85f07cfa3f933, already carried by ~22 sibling
repos. Once installed, re-dispatch via hermes kanban unblock t_fce6af3a.

Note on the CI work itself: the diagnosis in this issue (GitHub-hosted JS actions not
resolvable from this Forgejo instance) is untouched by this blocker and still stands
as the work to be done once the runner can launch.

kanban card t_fce6af3a — blocked pending operator gate install.

**Automated runner (kilo-gsd-runner) could not launch on this issue.** No code was changed. **Blocker:** this repo has no pre-dispatch gate at `.gsd/gates/pre-dispatch.sh`. ``` cd /home/b/Projects/Drift && bash .gsd/gates/pre-dispatch.sh 7 bash: .gsd/gates/pre-dispatch.sh: No such file or directory GATE_EXIT=127 ``` The runner shells this gate unconditionally between its Plan and Implement phases. A missing file returns exit 127, which is recorded as a gate FAILURE (not "no gate configured") and routed to the mechanical bugfix agent, which then scaffolds a bespoke gate and burns its retry budget. Launching into that is worse than stopping, so the run was not started. **Every other precondition is green:** - worktree `/home/b/Projects/Drift` clean, HEAD `2be3641` on `main` - no live runner process or tmux session for this issue - no commit on `origin/main` referencing `#7` - issue open, labels `bug` / `triage-approved` **Fixed in passing:** the repo had no `in-progress` label defined, which would have made the runner's claim step fail with a 422. It now exists (id 1182), so that will not block the next attempt. **Operator remedy** (`.gsd/` is gitignored, operator-provisioned tooling state — the launcher is not permitted to create it): ``` install -D -m 755 /home/b/Projects/infrastructure/.gsd/gates/pre-dispatch.sh \ /home/b/Projects/Drift/.gsd/gates/pre-dispatch.sh ``` Canonical gate `md5=71f169a29925057bece85f07cfa3f933`, already carried by ~22 sibling repos. Once installed, re-dispatch via `hermes kanban unblock t_fce6af3a`. Note on the CI work itself: the diagnosis in this issue (GitHub-hosted JS actions not resolvable from this Forgejo instance) is untouched by this blocker and still stands as the work to be done once the runner can launch. <sub>kanban card `t_fce6af3a` — blocked pending operator gate install.</sub>
Mark commented 2026-09-15 16:33:18 +00:00
Author
Owner
Copy link

kanban launcher check 2026-09-15: gate preflight fails — Drift repo has no .gsd/gates/pre-dispatch.sh (operator-only tooling state). Local issue and CI symptom are unchanged. kilo-gsd.py cannot fly until the operator installs the canonical gate (md5=71f169a29925057bece85f07cfa3f933, located at /home/b/Projects/infrastructure/.gsd/gates/pre-dispatch.sh). Operator one-liner:

install -m 755 /home/b/Projects/infrastructure/.gsd/gates/pre-dispatch.sh /home/b/Projects/Drift/.gsd/gates/pre-dispatch.sh

After install, kanban card t_1a39a080 will be unblocked and re-dispatched; this Forgejo issue will then get the actual CI rewrite (drop actions/checkout@v4 and actions/setup-node@v4, replace with container: catthehacker/ubuntu:act-22.04 + plain git clone/npm ci steps).

kanban launcher check 2026-09-15: gate preflight fails — Drift repo has no `.gsd/gates/pre-dispatch.sh` (operator-only tooling state). Local issue and CI symptom are unchanged. kilo-gsd.py cannot fly until the operator installs the canonical gate (`md5=71f169a29925057bece85f07cfa3f933`, located at `/home/b/Projects/infrastructure/.gsd/gates/pre-dispatch.sh`). Operator one-liner: ``` install -m 755 /home/b/Projects/infrastructure/.gsd/gates/pre-dispatch.sh /home/b/Projects/Drift/.gsd/gates/pre-dispatch.sh ``` After install, kanban card t_1a39a080 will be unblocked and re-dispatched; this Forgejo issue will then get the actual CI rewrite (drop `actions/checkout@v4` and `actions/setup-node@v4`, replace with `container: catthehacker/ubuntu:act-22.04` + plain `git clone`/`npm ci` steps).
Mark closed this issue 2026-09-16 19:01:39 +00:00
Mark commented 2026-09-17 18:17:36 +00:00
Author
Owner
Copy link

Verification — workflow now passes end-to-end

Root cause was NOT the third-party action theory. Commit 710627d0 (the container rewrite) actually did fix the original actions/checkout@v4 failure. New run #7032 (commit 71c93905, fix for #8) failed on npm run check because the pushed commit deliberately shipped with a known TypeScript regression — the author's own commit message says verbatim:

Verified: npm ci exits 0 (no ERESOLVE), npm run build succeeds, npm run check still fails (drizzle-orm schema overload errors) — separate bug

Fix shipped: 8bfee31 "fix(#9): clear drizzle-orm schema overload errors blocking npm run check". Drops the seven dead *Sqlite drizzle table declarations in shared/schema.ts (runtime SQLite uses raw CREATE TABLE in server/db.ts#createSqliteTables, so they produced only TS errors). Also adjusts users.email default, normalizes insertActionSchema.dueDate to Date | null, fixes req.params.id type casts, extends the logger to accept a structured meta object, and narrows the db type so storage.ts's pg-typed table references resolve.

Result:

  • New run #7043 (commit 8bfee31, index_in_repo=20) — status: success ✅
  • Issue #7 was prematurely closed on 2026-09-16 — none of its three acceptance criteria were passing at that point. Re-opening it on the strength of this run.

Issue #7 acceptance criteria, current status

  1. ✅ npm ci / npm run check / npm run build end-to-end success on the newest push to main — verified against run #7043.
  2. ✅ Newest run status success with green steps — verified via the run summary (web UI) and the run's status field.
  3. ⚠️ GET /api/v1/repos/AuWoMe/Drift/actions/runs/<id>/jobs still returns HTTP 404 — but this is NOT caused by the workflow. Spot-checked: the same 404 affects every run in this repo (7043, 7032, 6988, 6987, 6985, 6981, 6980, 6979, 6996, 2674, 1) and every run in every other repo on this Forgejo instance (e.g. Mark/org_mode runs 1–3 all 404 the same way). The run metadata API works, but /jobs, /logs, /artifacts, and /steps sub-resources all 404 repo-wide. The web UI loads the page but redirects to login for any …/jobs/0/attempt/1 link.
    • This looks like a Forgejo 13.0.4 instance-level config problem — likely one of: forgejo_actions_log_path not configured, the runner writing to a path that isn't being read back into the Forgejo log DB, or the Actions storage path not mounted. Needs an operator to investigate the instance config; it cannot be fixed by changes inside this repo.

Closing the workflow side of this issue. The Jobs API 404 needs a separate operator ticket.

## Verification — workflow now passes end-to-end **Root cause was NOT the third-party action theory.** Commit `710627d0` (the container rewrite) actually did fix the original `actions/checkout@v4` failure. New run #7032 (commit `71c93905`, fix for #8) failed on `npm run check` because the pushed commit deliberately shipped with a known TypeScript regression — the author's own commit message says verbatim: > Verified: npm ci exits 0 (no ERESOLVE), npm run build succeeds, npm run check still fails (drizzle-orm schema overload errors) — separate bug **Fix shipped:** `8bfee31` "fix(#9): clear drizzle-orm schema overload errors blocking npm run check". Drops the seven dead `*Sqlite` drizzle table declarations in `shared/schema.ts` (runtime SQLite uses raw `CREATE TABLE` in `server/db.ts#createSqliteTables`, so they produced only TS errors). Also adjusts `users.email` default, normalizes `insertActionSchema.dueDate` to `Date | null`, fixes `req.params.id` type casts, extends the logger to accept a structured meta object, and narrows the `db` type so storage.ts's pg-typed table references resolve. **Result:** - New run **#7043** (commit `8bfee31`, `index_in_repo=20`) — **status: `success`** ✅ - Started `2026-09-17T18:13:21Z`, stopped `2026-09-17T18:15:30Z`, duration 2 min 9 sec - URL: https://forgejo.tail018ac4.ts.net/AuWoMe/Drift/actions/runs/20 - All four steps green (Checkout code, Install dependencies, TypeScript check, Build) - Issue #7 was prematurely closed on 2026-09-16 — none of its three acceptance criteria were passing at that point. Re-opening it on the strength of this run. ## Issue #7 acceptance criteria, current status 1. ✅ `npm ci` / `npm run check` / `npm run build` end-to-end `success` on the newest push to `main` — verified against run #7043. 2. ✅ Newest run status `success` with green steps — verified via the run summary (web UI) and the run's `status` field. 3. ⚠️ `GET /api/v1/repos/AuWoMe/Drift/actions/runs/<id>/jobs` still returns **HTTP 404** — but this is **NOT** caused by the workflow. Spot-checked: the same 404 affects every run in this repo (7043, 7032, 6988, 6987, 6985, 6981, 6980, 6979, 6996, 2674, 1) and every run in every other repo on this Forgejo instance (e.g. `Mark/org_mode` runs 1–3 all 404 the same way). The run metadata API works, but `/jobs`, `/logs`, `/artifacts`, and `/steps` sub-resources all 404 repo-wide. The web UI loads the page but redirects to login for any `…/jobs/0/attempt/1` link. - This looks like a Forgejo 13.0.4 instance-level config problem — likely one of: `forgejo_actions_log_path` not configured, the runner writing to a path that isn't being read back into the Forgejo log DB, or the Actions storage path not mounted. Needs an operator to investigate the instance config; it cannot be fixed by changes inside this repo. Closing the workflow side of this issue. The Jobs API 404 needs a separate operator ticket.
Mark reopened this issue 2026-09-17 18:17:40 +00:00
Mark closed this issue 2026-09-18 14:07:50 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
bug

A defect or broken behavior

  
in-progress

claimed by an automated runner

  
triage-approved

Routed to lane runner via Forgejo webhook

No labels
bug
in-progress
triage-approved
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
AuWoMe/Drift#7
No description provided.