ehoandClaude Opus 4.8
c404995980
CodeQL is GitHub-only — its analyze step uploads SARIF to GitHub's code-scanning API and assumes a GitHub Security tab; this CI runs on Gitea only, so the job could never go green (it had been red since it was added). Replace it with Semgrep OSS, a plain CLI SAST with no account/platform API, which runs fine on Gitea. - Remove the codeql job (+ its security-events permission) and the schedule trigger (it existed only for codeql; semgrep runs on push + PR). - Add a semgrep job: setup-python + `pip install semgrep` + `semgrep scan --config p/default --config p/csharp --metrics=off`. pip-on-runner (not container:) mirrors the other jobs' model; anonymous registry, telemetry off. - Report-only for now (no --error → job stays green): a local dry-run found 27 findings, mostly CI/config policy (unpinned actions, .npmrc), not app-code vulns. WP-30 tracks triaging them + flipping to --error (a blocking gate). Verified locally: `semgrep scan` runs clean (exit 0 without --error, 306 rules / 450 files). CI behaviour confirmable only on the Gitea runner — watch the run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.9 KiB
3.9 KiB
WP-30 — CI performance follow-ups
Status: todo Phase: follow-on · CI/infra
Why
Tier-1 CI speedups shipped in 708d4c2 (CodeQL off the PR path, Playwright/NuGet caches,
npm ci flags) and the demo web image shrank to node:24-slim. These are the remaining
options that were deliberately deferred — bigger changes, policy calls, or things that need
Gitea runner-admin access. Revisit once there's an actual CI-timing breakdown to prioritise by,
or when someone confirms act_runner access.
Constraint carried over: CI runs are not observable from the agent's environment — validate
any workflow edit by watching a real Gitea run; ship one change at a time so a red run is easy to
bisect and revert. The docker compose images are NOT used by CI (CI = Gitea ubuntu-latest
runner image, set on the act_runner host).
Read first
.github/workflows/ci.yml(current 6 jobs + the Tier-1 caches already in place).- The
ci-and-local-gatenote (agent memory) — CI traps + what's already done. docker-compose.yml(demo images;node:24-slimdone, dotnet SDK still full).
Candidate items (pick per impact once measured)
- Skip
npm ciinstall via anode_modulescache.actions/cacheonnode_moduleskeyed bypackage-lock.jsonhash; on a hit,npm ciis near-instant across the 4 npm jobs. Bigger win than the existing npm-download cache, but a ~777 MB cache with a small staleness risk — best if the runner's cache storage is local/fast. Medium effort, low-medium risk. - Smaller CI runner image.
- Real fix (needs runner admin): point act_runner's
ubuntu-latest(or a new label) at a smaller image with node + dotnet preinstalled. Biggest startup win. Blocked on confirming act_runner access. - Repo-only partial:
container: node:24-slimon the node-only jobs (frontend,storybook-a11y), droppingsetup-node. Doesn't help the node+dotnet jobs (e2e,api-client-drift,backend) — a combined image would need building/pushing (new infra). Risky on act_runner, unverifiable locally → stage alone, last.
- Real fix (needs runner admin): point act_runner's
- Path-filtered jobs. Skip
backendon FE-only changes and vice-versa (workflowpaths:ordorny/paths-filter). Cuts compute on narrow PRs; watch required-check rules that expect every job to report a status. - Split a fast
lintjob (lint + format:check + check:tokens) for ~1 min fail-fast feedback — only worth it once item 1 (node_modules cache) lands, else it duplicatesnpm ci. - Lean deployable backend image (optional, not for the dev demo): multi-stage prod build on
mcr.microsoft.com/dotnet/aspnet:10.0(~220 MB) in a separatedocker-compose.prod.yml. The devdocker-compose.ymlkeeps the SDK image becausedotnet runhot-reload needs it. - Semgrep: triage findings + make it blocking. Semgrep replaced CodeQL (GitHub-only, couldn't
run on Gitea) and currently runs report-only — a local dry-run found 27 findings, mostly
CI/config policy (unpinned GitHub Actions in
ci.yml,.npmrcmin-release-age) rather than app-code vulns. Triage them (fix or# nosemgrep/.semgrepignorethe noise; consider a tighter ruleset thanp/defaultif the GitHub-Actions-policy rules aren't wanted), then add--errortosemgrep scanso it's a real gate.
Acceptance criteria
- Each chosen item verified GREEN on a real Gitea run (watched, since it's not observable from the agent env), landed as its own revertable commit.
npm run cistill passes locally after any workflow/script change.
Out of scope
- nx/turbo/remote build caching (overkill for this repo size).
- Rewriting the dev compose into prod images (would lose bind-mount hot reload).
Risks
- Unverifiable-from-agent workflow edits can only be confirmed on the runner — one change per commit, revert on red.
- act_runner-level changes depend on infra access this repo doesn't control.