Fleet-wide CI-speed pass: none of 0pt's push/pull_request-triggered
workflow jobs capped their own runtime, so a hang (network stall,
runaway process, stuck polling loop) burns a runner slot until Gitea's
own default kicks in. Added job-level timeout-minutes sized to what
each job actually does:
cd.yml deploy 20 (bounded ~10min signed-artifact poll + setup)
ci.yml quality 30 (typecheck/test/build)
ci.yml integration 45 (multi-service: live OpenSearch + ClickHouse)
ci.yml security 15 (single trivy fs scan)
security.yml security 15 (single trivy fs scan)
masterplan-lock.yml check 10 (single dependency-free shell check)
release.yml release 45 (docker build/push + full G17 SBOM/scan/attest/verify chain)
Deliberately NOT included in this PR: a concurrency: block for
ci.yml/security.yml/masterplan-lock.yml's push+pull_request double-
trigger. ci.yml's own `integration` job comment already documents,
measured live (runs 28904/28906), that "Gitea currently ignores
workflow concurrency" on this fleet, and the repo's real fix for the
resulting double-run-on-shared-service-containers problem is the
self-identifying-container pattern already in that job, not a
concurrency group. Adding an inert concurrency: block here would give
false confidence that the duplicate-run problem is handled when it
measurably is not. Left for a follow-up decision once that fleet-wide
finding is resolved.
Part of a fleet-wide CI-speed pass (timeout-minutes audit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
