Fix repeatedly failing scheduled dependency check #45

New Issue

MrSphay · 2026-07-03T20:56:24Z

MrSphay commented

2026-07-03 20:56:24 +00:00

Observed problem

The scheduled dependency workflow now fails repeatedly on the unchanged production commit c159c83a.

Observed failed runs include:

run 224
run 227
run 230

Earlier runs for the same commit succeeded, so the failure may be caused by a newly reported dependency vulnerability, registry/network behavior, or runner/toolchain drift. The API does not expose usable job logs for these runs; inspect the Gitea Actions UI before changing dependencies.

Impact

Dependency health is no longer continuously verified and the repository remains red even though build, release dry-run, template compliance, and cleanup pass.

Affected files

.gitea/workflows/dependency-check.yml
package.json
package-lock.json
potentially Dockerfile

Acceptance criteria

Identify the exact failing command from the latest runner log.
Fix the dependency, lockfile, workflow, or runner compatibility issue without suppressing real audit findings.
Keep the workflow report-only; it must not modify dependencies or create PRs automatically.
Trigger the workflow on a supported Gitea Ubuntu runner and confirm a successful terminal result.
Record intentionally held dependency versions in project documentation when applicable.

## Observed problem The scheduled dependency workflow now fails repeatedly on the unchanged production commit `c159c83a`. Observed failed runs include: - run 224 - run 227 - run 230 Earlier runs for the same commit succeeded, so the failure may be caused by a newly reported dependency vulnerability, registry/network behavior, or runner/toolchain drift. The API does not expose usable job logs for these runs; inspect the Gitea Actions UI before changing dependencies. ## Impact Dependency health is no longer continuously verified and the repository remains red even though build, release dry-run, template compliance, and cleanup pass. ## Affected files - `.gitea/workflows/dependency-check.yml` - `package.json` - `package-lock.json` - potentially `Dockerfile` ## Acceptance criteria - Identify the exact failing command from the latest runner log. - Fix the dependency, lockfile, workflow, or runner compatibility issue without suppressing real audit findings. - Keep the workflow report-only; it must not modify dependencies or create PRs automatically. - Trigger the workflow on a supported Gitea Ubuntu runner and confirm a successful terminal result. - Record intentionally held dependency versions in project documentation when applicable.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Code-Inc/intelligence-terminal#45