chore: harden CI workflows and clear lint debt#55
Conversation
Three workflows have echo-only "disabled-target" jobs that fall back to GitHub's 360-minute job default. Even trivial echo jobs deserve an explicit small timeout to bound runner exposure on stalled steps.
Three write-side workflows lacked a top-level concurrency: block: - repair-comment-router.yml (cron */5min + repository_dispatch) - repair-self-heal.yml (cron 17,47 hourly) - repair-finalize-open-prs.yml (workflow_dispatch only) Without a group, overlapping cron/dispatch runs can race each other on git push (rebase-strategy=theirs ledger commits) and dispatch worker slots. comment-router uses a per-target dynamic group to keep parallel target-repo runs separate; self-heal and finalize-open-prs use static singleton groups since they operate fleet-wide. cancel-in-progress is false everywhere — these workflows write ledger state and should not be interrupted mid-publish.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7606340da4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| concurrency: | ||
| group: repair-comment-router-${{ github.event.inputs.target_repo || github.event.client_payload.target_repo || 'openclaw/openclaw' }} | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
This new top-level concurrency block can drop repository_dispatch events under load because GitHub Actions defaults concurrency queues to single pending run: when a second pending run arrives, the older pending run is canceled and replaced even with cancel-in-progress: false. In this workflow, that means if one run is active and multiple comment dispatches arrive, intermediate comment-router runs can be discarded, so some commands may never be routed (especially when schedule-based execute is disabled). Add queue: max (or another explicit queue strategy) to avoid losing queued events.
Useful? React with 👍 / 👎.
|
@clawsweeper automerge |
| name: Skip disabled target commit review | ||
| if: ${{ github.event_name == 'repository_dispatch' && github.event.client_payload.target_repo == 'openclaw/clawhub' && vars.CLAWSWEEPER_ENABLE_CLAWHUB != '1' }} | ||
| runs-on: ubuntu-latest | ||
| timeout-minutes: 5 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4237d2fb3d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| CLAWSWEEPER_APP_CLIENT_ID: Iv23liOECG0slfuhz093 | ||
|
|
||
| concurrency: | ||
| group: repair-comment-router-${{ github.event.inputs.target_repo || github.event.client_payload.target_repo || 'openclaw/openclaw' }} |
There was a problem hiding this comment.
Update the workflow-level concurrency group to include the same schedule-time target resolution used by the router step. Right now the group only checks github.event.inputs.target_repo and github.event.client_payload.target_repo, then falls back to 'openclaw/openclaw', but scheduled runs actually use vars.CLAWSWEEPER_TARGET_REPO when choosing --repo in the routing step. If that variable is set to a non-default repo, those runs are still placed in the openclaw/openclaw concurrency group, so unrelated target repos can block/cancel each other under concurrency limits and drop routing cycles.
Useful? React with 👍 / 👎.
2 participants
Summary
Small hardening sweep that stays out of the 5 currently-open PRs' file footprints, so it can land independently without creating rebase friction.
What changed
ci: add timeout-minutes to disabled-target echo jobs(cd5e884)Three workflows have echo-only "disabled-target" guard jobs that fall back to GitHub's 360-minute job default. Even trivial echo jobs deserve an explicit small timeout to bound runner exposure on stalled steps.
.github/workflows/commit-review.yml—disabled-targetjob.github/workflows/repair-commit-finding-intake.yml—disabled-targetjob.github/workflows/sweep.yml—event-disabled-targetjobAll three set
timeout-minutes: 5.ci: add concurrency groups to write-side repair workflows(7606340)Three write-side workflows lacked a top-level
concurrency:block:repair-comment-router.yml— runs on cron*/5 * * * *PLUSrepository_dispatch. Without a group, a slow run can be overlapped by the next cron tick (or a dispatch event), and both will race on the GitHub API + git push side. Uses a per-target dynamic group so parallel target-repo runs stay separate.repair-self-heal.yml— runs on cron17,47 * * * *. Singleton group since it operates fleet-wide.repair-finalize-open-prs.yml—workflow_dispatchonly, but still write-side and writesrepair-apply-report.jsonledger. Singleton group.cancel-in-progress: falseon all three — these workflows write ledger state and should not be interrupted mid-publish.Why
timeout-minuteson echo-only guard jobs (3 spots), missing top-levelconcurrency:on write-side workflows that share ledger files (3 spots).pnpm run lint:scriptsandpnpm run format:checkwere already clean.Validation
pnpm run checkpasses green: 357 tests, lint 0 errors, format clean.github/workflows/*.yml(6 lines added, 0 removed effective)Scope discipline
This PR explicitly does NOT modify
src/clawsweeper.ts,src/repair/comment-router*,src/repair/github-cli.ts,src/repair/plan-cluster.ts, orsrc/policy-rfc/**, so it can be merged in any order relative to PR#52/#53/#50/#49/#39.