ci(nightly): surface a clear error when the Gitea API rejects the audit token #840

marcel · 2026-06-14T19:31:09+02:00

marcel commented

2026-06-14 19:31:09 +02:00

What

The npm-audit job in nightly.yml filed its tracking issue via curl -sf, which collapses every HTTP >= 400 into a bare exit 22. When NIGHTLY_AUDIT_TOKEN is rejected (missing/expired/under-scoped), the step died with an opaque exitcode '22' and no hint at the cause — exactly what happened on run #6707 (the audit correctly found the tmp high advisory, then couldn't authenticate to file the issue).

Change

Add an api() helper that reads the HTTP status code and, on >= 400, emits an actionable ::error:: naming the status and the NIGHTLY_AUDIT_TOKEN secret (value/scope) before failing the step — never echoing the token value.
Route all five API calls (list issues, patch, create, list labels, add labels) through it.
Extend the in-workflow self-test with a mocked-curl check covering both the success path (2xx returns body) and the error path (>= 400 emits ::error::, fails).

Behaviour on success is unchanged; the step still fails non-zero on error (clarity does not mask the failure).

Verification

Red→green TDD on the helper logic (200/201 return body; 401/500 emit ::error::, return non-zero; token never leaked).
Integration test with mocked curl: create-new and update-existing paths both work; a 401-on-create now prints a clear ::error:: and fails cleanly instead of exit 22.
Self-test block executed in-place under set -eo pipefail; YAML parses; npm run lint clean.

Note (not in this PR)

This only fixes the opaque failure mode. The job will still go red by design (exit "$AUDIT_EXIT") while the real tmp advisory (GHSA-ph9p-34f9-6g65) is open, and the token itself must be repaired operationally (recreate the renovate_bot PAT with issue read+write scope and update the secret).

Closes #839

🤖 Generated with Claude Code

## What The `npm-audit` job in `nightly.yml` filed its tracking issue via `curl -sf`, which collapses every HTTP >= 400 into a bare `exit 22`. When `NIGHTLY_AUDIT_TOKEN` is rejected (missing/expired/under-scoped), the step died with an opaque `exitcode '22'` and no hint at the cause — exactly what happened on run #6707 (the audit correctly found the `tmp` high advisory, then couldn't authenticate to file the issue). ## Change - Add an `api()` helper that reads the HTTP status code and, on >= 400, emits an actionable `::error::` naming the status and the `NIGHTLY_AUDIT_TOKEN` secret (value/scope) before failing the step — never echoing the token value. - Route all five API calls (list issues, patch, create, list labels, add labels) through it. - Extend the in-workflow self-test with a mocked-`curl` check covering both the success path (2xx returns body) and the error path (>= 400 emits `::error::`, fails). Behaviour on success is unchanged; the step still fails non-zero on error (clarity does not mask the failure). ## Verification - Red→green TDD on the helper logic (200/201 return body; 401/500 emit `::error::`, return non-zero; token never leaked). - Integration test with mocked `curl`: create-new and update-existing paths both work; a 401-on-create now prints a clear `::error::` and fails cleanly instead of `exit 22`. - Self-test block executed in-place under `set -eo pipefail`; YAML parses; `npm run lint` clean. ## Note (not in this PR) This only fixes the *opaque failure mode*. The job will still go red by design (`exit "$AUDIT_EXIT"`) while the real `tmp` advisory (`GHSA-ph9p-34f9-6g65`) is open, and the token itself must be repaired operationally (recreate the `renovate_bot` PAT with issue read+write scope and update the secret). Closes #839 🤖 Generated with [Claude Code](https://claude.com/claude-code)

marcel added 1 commit 2026-06-14 19:31:09 +02:00

ci(nightly): surface a clear error when the Gitea API rejects the audit token

CI / Unit & Component Tests (push) Successful in 3m51s

Details

CI / OCR Service Tests (push) Successful in 23s

Details

CI / Unit & Component Tests (pull_request) Successful in 4m43s

Details

CI / Backend Unit Tests (push) Successful in 5m6s

Details

CI / fail2ban Regex (push) Successful in 48s

Details

CI / OCR Service Tests (pull_request) Successful in 23s

Details

CI / Backend Unit Tests (pull_request) Successful in 5m10s

Details

CI / Semgrep Security Scan (push) Successful in 23s

Details

CI / fail2ban Regex (pull_request) Successful in 47s

Details

CI / Compose Bucket Idempotency (push) Successful in 1m5s

Details

CI / Semgrep Security Scan (pull_request) Successful in 23s

Details

CI / Compose Bucket Idempotency (pull_request) Successful in 1m6s

Details

SDD Gate / RTM Check (pull_request) Successful in 13s

Details

SDD Gate / Contract Validate (pull_request) Successful in 24s

Details

SDD Gate / Constitution Impact (pull_request) Successful in 17s

Details

6dae4fe428

The npm-audit job filed its tracking issue via `curl -sf`, which collapses
every HTTP >=400 into a bare "exit 22". When the NIGHTLY_AUDIT_TOKEN secret is
missing, expired, or under-scoped, the step failed with an opaque
`exitcode '22'` and no hint at the cause (run #6707).

Route all five API calls through an `api()` helper that reads the HTTP status
and, on >=400, emits an actionable `::error::` naming the status and the token
secret before failing — without ever echoing the token value. Extend the
in-workflow self-test (mocked curl) to cover both the success and HTTP-error
paths.

Closes #839
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

marcel added the P2-medium devops labels 2026-06-14 19:31:11 +02:00

marcel merged commit 6dae4fe428 into main

2026-06-14 19:58:05 +02:00

marcel deleted branch devops/issue-839-nightly-audit-clear-error

2026-06-14 19:58:06 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#840