Added timeout-minutes to all three jobs, which had none: quality (30), contracts (30) — both install/typecheck/test/build style jobs — and security (15), a single Trivy scan. Without this, a hung step could tie up a runner indefinitely.
Added a top-level concurrency block (group keyed on workflow + ref, cancel-in-progress: true). This workflow triggers on both push (unfiltered) and pull_request, so every PR commit was running the full CI suite twice. The concurrency group cancels the superseded run instead of changing what triggers CI. Same pattern already used in admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n.
masterplan-lock.yml is schedule-only (not on the push/PR hot path) and was left untouched.
No triggers, job logic, caching, matrix, or needs: were changed.
Part of a fleet-wide CI-speed pass.
What changed in `.gitea/workflows/ci.yml`:
- Added `timeout-minutes` to all three jobs, which had none: `quality` (30), `contracts` (30) — both install/typecheck/test/build style jobs — and `security` (15), a single Trivy scan. Without this, a hung step could tie up a runner indefinitely.
- Added a top-level `concurrency` block (group keyed on workflow + ref, `cancel-in-progress: true`). This workflow triggers on both `push` (unfiltered) and `pull_request`, so every PR commit was running the full CI suite twice. The concurrency group cancels the superseded run instead of changing what triggers CI. Same pattern already used in admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n.
`masterplan-lock.yml` is schedule-only (not on the push/PR hot path) and was left untouched.
No triggers, job logic, caching, matrix, or `needs:` were changed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Part of a fleet-wide CI-speed pass. ci.yml's three jobs (quality,
security, contracts) had no timeout-minutes, so a hung step could run
indefinitely and tie up a scarce runner. Added 30min for the
build/test jobs (quality, contracts) and 15min for the single-check
security scan (Trivy).
ci.yml also triggers on both push and pull_request with no branch
filter, which fires the full CI suite twice per PR commit. Added the
same concurrency group pattern already used elsewhere in the fleet
(admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n) to cancel the
superseded run instead of changing the triggers themselves.
masterplan-lock.yml is schedule-only and not on the hot path, so left
untouched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of a fleet-wide CI-speed pass.
What changed in
.gitea/workflows/ci.yml:timeout-minutesto all three jobs, which had none:quality(30),contracts(30) — both install/typecheck/test/build style jobs — andsecurity(15), a single Trivy scan. Without this, a hung step could tie up a runner indefinitely.concurrencyblock (group keyed on workflow + ref,cancel-in-progress: true). This workflow triggers on bothpush(unfiltered) andpull_request, so every PR commit was running the full CI suite twice. The concurrency group cancels the superseded run instead of changing what triggers CI. Same pattern already used in admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n.masterplan-lock.ymlis schedule-only (not on the push/PR hot path) and was left untouched.No triggers, job logic, caching, matrix, or
needs:were changed.🤖 Generated with Claude Code