Part of a fleet-wide CI-speed pass (audit already scoped this repo).
This repo has one workflow, .gitea/workflows/masterplan-lock.yml, and it had both of the issues this pass targets:
Missing timeout-minutes on the check job. It's a cheap, dependency-free POSIX-sh check (no toolchain), so a 10-minute job-level timeout is added as a safety net against a hung runner.
Double-trigger waste: the workflow runs on both push (branches: ["**"], i.e. every branch including any a PR could target) and pull_request, so every PR commit ran the same check twice. Added a top-level concurrency: block (same pattern already used in admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n) so the superseded duplicate run is cancelled. The on: triggers themselves are unchanged.
No other changes: caching, action pinning, job logic, and branch protection are all left untouched.
Part of a fleet-wide CI-speed pass (audit already scoped this repo).
This repo has one workflow, `.gitea/workflows/masterplan-lock.yml`, and it had both of the issues this pass targets:
1. **Missing `timeout-minutes`** on the `check` job. It's a cheap, dependency-free POSIX-sh check (no toolchain), so a 10-minute job-level timeout is added as a safety net against a hung runner.
2. **Double-trigger waste**: the workflow runs on both `push` (`branches: ["**"]`, i.e. every branch including any a PR could target) and `pull_request`, so every PR commit ran the same check twice. Added a top-level `concurrency:` block (same pattern already used in admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n) so the superseded duplicate run is cancelled. The `on:` triggers themselves are unchanged.
No other changes: caching, action pinning, job logic, and branch protection are all left untouched.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Fleet-wide CI-speed pass: masterplan-lock.yml had no job-level
timeout-minutes (a hung runner could block indefinitely) and triggers
on both push (branches: ["**"]) and pull_request, which runs the same
check twice per PR commit. Add a 10-minute timeout for this cheap
single-check job and a concurrency group (matching the pattern already
used in admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n) to cancel
the superseded duplicate run without changing what triggers CI.
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 (audit already scoped this repo).
This repo has one workflow,
.gitea/workflows/masterplan-lock.yml, and it had both of the issues this pass targets:timeout-minuteson thecheckjob. It's a cheap, dependency-free POSIX-sh check (no toolchain), so a 10-minute job-level timeout is added as a safety net against a hung runner.push(branches: ["**"], i.e. every branch including any a PR could target) andpull_request, so every PR commit ran the same check twice. Added a top-levelconcurrency:block (same pattern already used in admin/serv0, admin/s0cial, admin/ppl0, admin/pers0n) so the superseded duplicate run is cancelled. Theon:triggers themselves are unchanged.No other changes: caching, action pinning, job logic, and branch protection are all left untouched.
🤖 Generated with Claude Code