runner(debian-testing): MISE_GITHUB_TOKEN is invalid and mise cache backend is unreachable #3

Closed
opened 2026-08-25 20:16:13 +00:00 by ses · 1 comment
Owner

Two environment-wide bugs surfaced while bringing sebatec-eu/forgejo-mcp!5 to green on debian-testing. Both are configuration issues on the ghcr.io/sebatec-eu/testing-forgejo-runner image (or its runner registration), not in the forgejo-mcp codebase.


Bug 1 — MISE_GITHUB_TOKEN is set but invalid

Observed (every CI run, e.g. forgejo-mcp!5 run #8 / #9)

mise bun@1.4.0       [1/3] download bun-linux-x64.zip
mise biome@2.5.10    [1/2] install
mise biome@2.5.10    [1/2] download biome-linux-x64
mise WARN  [biomejs/biome] failed to fetch version tags, URL may be incorrect: HTTP status client error (401 Unauthorized) for url (https://api.github.com/repos/biomejs/biome/releases?per_page=100)
github auth: yes (token from MISE_GITHUB_TOKEN)
github response: {
  "message": "Bad credentials",
  "documentation_url": "https://docs.github.com/rest",
  "status": "401"
}
hint: the token in `MISE_GITHUB_TOKEN` was rejected by GitHub (401 Unauthorized). ...

The MISE_GITHUB_TOKEN env var on the runner is either unset (empty string) or holds an expired/revoked GitHub PAT. mise reports auth: yes because the variable is set, but GitHub returns 401 Bad credentials.

Impact

  • Non-blocking: mise falls back to direct-release download + artifact-attestation verification, and bun / biome install correctly. So jobs still succeed.
  • Cosmetic + slow: every CI run on debian-testing does the full ~5s fallback download that the GitHub-authenticated path would have short-circuited.
  • Misleading logs: the Bad credentials warning appears on every run, drowning other warnings.

Suggested fix

Either unset MISE_GITHUB_TOKEN on the runner, or rotate it to a valid GitHub PAT with the necessary scopes for the actions/mise-action path. If no PAT is desired, simply remove the env var from the runner registration and the warning disappears.


Bug 2 — Mise cache cannot reach the cache backend (getaddrinfo ENOTFOUND forge.sebatec.eu_apis)

Observed (every CI run, e.g. forgejo-mcp!5 run #8 / #9)

##[group]Restoring mise cache
::warning::Failed to restore: getCacheEntry failed: getaddrinfo ENOTFOUND forge.sebatec.eu_apis
mise cache not found for mise-v1-linux-x64-debiantesting-...
Using curl to download mise
...
##[group]Saving mise cache
::warning::Failed to save: reserveCache failed: getaddrinfo ENOTFOUND forge.sebatec.eu_apis

The cache host alias forge.sebatec.eu_apis is unreachable from inside the runner container. Every job does a full mise download instead of a cache restore, and the cache it produces after the run is discarded.

Impact

  • Non-blocking: jobs succeed.
  • ~25s wasted on every CI run on debian-testing (mise download + biome/bun re-extraction).
  • Cache thrash: no runner benefits from a previous runner's mise install.

Suggested fix

Either (a) add the forge.sebatec.eu_apis host alias (or the actual cache-backend DNS) to the runner image / network, or (b) drop the actions/cache calls for mise-v1-... keys when the backend is unreachable. Option (a) is preferable — once cache is reachable, every other Actions job on this runner image benefits.


Out of scope (informational, not bugs in this tracker)

  • The bun install "tempdir: EACCES" issue that surfaces on AppImage-distributed bun installs (e.g. opencode's bundled bun, the bun on /usr/local/bin/bun in some dev sandboxes) is an upstream Bun installer bug resolved by oven-sh/bun!32634 / commit 5bec0252. It does not affect CI here because CI installs bun via the Debian/mise path. Mentioning it for completeness; the fix is in Bun, not in our runner image.
  • The lockfile drift on sebatec-mcp!5 itself was an application-side issue (a package.json mutation in commit 1 of the PR shipped without its bun.lock update). Fixed in commit fb794e8 on the branch.
Two environment-wide bugs surfaced while bringing `sebatec-eu/forgejo-mcp!5` to green on `debian-testing`. Both are configuration issues on the `ghcr.io/sebatec-eu/testing-forgejo-runner` image (or its runner registration), not in the forgejo-mcp codebase. --- ## Bug 1 — `MISE_GITHUB_TOKEN` is set but invalid ### Observed (every CI run, e.g. forgejo-mcp!5 run #8 / #9) ``` mise bun@1.4.0 [1/3] download bun-linux-x64.zip mise biome@2.5.10 [1/2] install mise biome@2.5.10 [1/2] download biome-linux-x64 mise WARN [biomejs/biome] failed to fetch version tags, URL may be incorrect: HTTP status client error (401 Unauthorized) for url (https://api.github.com/repos/biomejs/biome/releases?per_page=100) github auth: yes (token from MISE_GITHUB_TOKEN) github response: { "message": "Bad credentials", "documentation_url": "https://docs.github.com/rest", "status": "401" } hint: the token in `MISE_GITHUB_TOKEN` was rejected by GitHub (401 Unauthorized). ... ``` The `MISE_GITHUB_TOKEN` env var on the runner is either unset (empty string) or holds an expired/revoked GitHub PAT. mise reports `auth: yes` because the variable is set, but GitHub returns `401 Bad credentials`. ### Impact - Non-blocking: mise falls back to direct-release download + artifact-attestation verification, and `bun` / `biome` install correctly. So jobs still succeed. - Cosmetic + slow: every CI run on `debian-testing` does the full ~5s fallback download that the GitHub-authenticated path would have short-circuited. - Misleading logs: the `Bad credentials` warning appears on every run, drowning other warnings. ### Suggested fix Either unset `MISE_GITHUB_TOKEN` on the runner, or rotate it to a valid GitHub PAT with the necessary scopes for the `actions/mise-action` path. If no PAT is desired, simply remove the env var from the runner registration and the warning disappears. --- ## Bug 2 — Mise cache cannot reach the cache backend (`getaddrinfo ENOTFOUND forge.sebatec.eu_apis`) ### Observed (every CI run, e.g. forgejo-mcp!5 run #8 / #9) ``` ##[group]Restoring mise cache ::warning::Failed to restore: getCacheEntry failed: getaddrinfo ENOTFOUND forge.sebatec.eu_apis mise cache not found for mise-v1-linux-x64-debiantesting-... Using curl to download mise ... ##[group]Saving mise cache ::warning::Failed to save: reserveCache failed: getaddrinfo ENOTFOUND forge.sebatec.eu_apis ``` The cache host alias `forge.sebatec.eu_apis` is unreachable from inside the runner container. Every job does a full mise download instead of a cache restore, and the cache it produces after the run is discarded. ### Impact - Non-blocking: jobs succeed. - ~25s wasted on every CI run on `debian-testing` (mise download + biome/bun re-extraction). - Cache thrash: no runner benefits from a previous runner's mise install. ### Suggested fix Either (a) add the `forge.sebatec.eu_apis` host alias (or the actual cache-backend DNS) to the runner image / network, or (b) drop the `actions/cache` calls for `mise-v1-...` keys when the backend is unreachable. Option (a) is preferable — once cache is reachable, every other Actions job on this runner image benefits. --- ## Out of scope (informational, not bugs in this tracker) - The `bun install` "tempdir: EACCES" issue that surfaces on AppImage-distributed bun installs (e.g. `opencode`'s bundled bun, the bun on `/usr/local/bin/bun` in some dev sandboxes) is an upstream **Bun installer bug** resolved by `oven-sh/bun!32634` / commit `5bec0252`. It does not affect CI here because CI installs bun via the Debian/mise path. Mentioning it for completeness; the fix is in Bun, not in our runner image. - The lockfile drift on `sebatec-mcp!5` itself was an application-side issue (a `package.json` mutation in commit 1 of the PR shipped without its `bun.lock` update). Fixed in commit `fb794e8` on the branch.
Author
Owner

Opened in error by an over-eager agent. Drafting offline; will re-file after human review. See linked PR #5 for reproduction logs: sebatec-eu/forgejo-mcp#5

Opened in error by an over-eager agent. Drafting offline; will re-file after human review. See linked PR #5 for reproduction logs: https://forge.sebatec.eu/sebatec-eu/forgejo-mcp/pulls/5
ses closed this issue 2026-08-25 20:17:33 +00:00
Sign in to join this conversation.
No labels
No milestone
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
sebatec-eu/sebatec-containers#3
No description provided.