CodeQL cannot run on Forgejo — decide what replaces it in Api, Ordo and Site #148

New issue

Open

opened 2026-08-03 19:43:45 +00:00 by manlycucumber · 0 comments

manlycucumber commented

2026-08-03 19:43:45 +00:00

Owner

codeql.yml runs on push, on PR, and weekly on a schedule, in Directorium/Api, Directorium/Ordo and Directorium/Site. It has never passed in any of them, and it cannot.

Until today it failed early, because the runner could not fetch the action at all:

git clone 'https://data.forgejo.org/github/codeql-action'
fatal: repository ... not found: exit status 128

That was an infrastructure fault and it is fixed — the runner now resolves actions against github.com. With the action fetching cleanly, Directorium/Api run 35 (task 2263) gets one step further and then:

::error::404 page not found
❌  Failure - Post Initialize CodeQL

codeql-action/init calls GitHub's code-scanning endpoints on GITHUB_API_URL, which under Actions-on-Forgejo points at Forgejo. Forgejo does not implement code scanning, so it answers 404. There is no token or setting that changes this: the action wants a service this forge does not have.

The workflow's own header explains what it is for:

CodeQL has no PHP analyzer, so it scans the GitHub Actions workflows here (supply-chain / injection risks in CI).

So the value is real and worth keeping — it is the only thing auditing these workflows — but the mechanism is GitHub-only. Three options, roughly in increasing order of effort:

Delete codeql.yml from the three repos. Honest, and stops a weekly red that trains everyone to ignore the CI column. Loses the check.
Keep the analysis, drop the upload — codeql-action/analyze takes upload: never with output:. Unverified against Forgejo; init may still 404 before analyze is reached, so this needs testing before it is adopted.
Replace with a Forgejo-native workflow linter — actionlint or zizmor are single binaries, run anywhere, and cover the same ground (injection via untrusted ${{ }}, unpinned actions, over-broad permissions). This is the option that keeps the intent.

Whichever is chosen, it should be applied to all three repos together — they carry byte-identical copies from the same template.

Related: while confirming this, deploy.yml in the same three repos turned out not to be valid YAML, which failed a check on every push independently of anything CI did (fixed in 273d897 / 95d1c89 / 18ece2a). Between them, those two workflows are the entire reason "CI red on Api, Ordo" appeared in every estate digest since 2026-07-12.

`codeql.yml` runs on push, on PR, and weekly on a schedule, in **`Directorium/Api`, `Directorium/Ordo` and `Directorium/Site`**. It has never passed in any of them, and it cannot. Until today it failed early, because the runner could not fetch the action at all: ``` git clone 'https://data.forgejo.org/github/codeql-action' fatal: repository ... not found: exit status 128 ``` That was an infrastructure fault and it is fixed — the runner now resolves actions against github.com. With the action fetching cleanly, `Directorium/Api` run 35 (task 2263) gets one step further and then: ``` ::error::404 page not found ❌ Failure - Post Initialize CodeQL ``` `codeql-action/init` calls GitHub's code-scanning endpoints on `GITHUB_API_URL`, which under Actions-on-Forgejo points at Forgejo. Forgejo does not implement code scanning, so it answers 404. There is no token or setting that changes this: the action wants a service this forge does not have. The workflow's own header explains what it is for: > CodeQL has no PHP analyzer, so it scans the GitHub Actions workflows here (supply-chain / injection risks in CI). So the *value* is real and worth keeping — it is the only thing auditing these workflows — but the *mechanism* is GitHub-only. Three options, roughly in increasing order of effort: 1. **Delete `codeql.yml`** from the three repos. Honest, and stops a weekly red that trains everyone to ignore the CI column. Loses the check. 2. **Keep the analysis, drop the upload** — `codeql-action/analyze` takes `upload: never` with `output:`. Unverified against Forgejo; `init` may still 404 before `analyze` is reached, so this needs testing before it is adopted. 3. **Replace with a Forgejo-native workflow linter** — `actionlint` or `zizmor` are single binaries, run anywhere, and cover the same ground (injection via untrusted `${{ }}`, unpinned actions, over-broad permissions). This is the option that keeps the intent. Whichever is chosen, it should be applied to all three repos together — they carry byte-identical copies from the same template. Related: while confirming this, `deploy.yml` in the same three repos turned out not to be valid YAML, which failed a check on *every* push independently of anything CI did (fixed in `273d897` / `95d1c89` / `18ece2a`). Between them, those two workflows are the entire reason "CI red on Api, Ordo" appeared in every estate digest since 2026-07-12.

No milestone

No project

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

Directorium/Api#148

No description provided.

Rows
Columns