Repository navigation
ci: queue every close-issues and compliance-close run (#151) - #152
Conversation
Both workflows share one concurrency group (workflow + ref; ref is always the default branch for schedule/dispatch) with cancel-in-progress: false but no queue: max, so a dispatch silently replaced a pending scheduled run. Add queue: max, mirroring the close-prs fix in #133.
|
Hey! Your PR title Please update it to start with one of:
Where See CONTRIBUTING.md for details. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 72 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 41 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
The following comment was made by an LLM, it may be inaccurate: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3f88beb32f
ℹ️ 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: ${{ github.workflow }}-${{ github.ref }} | ||
| cancel-in-progress: false | ||
| queue: max |
There was a problem hiding this comment.
Use a ref-independent group to serialize every dispatch
In both inspected workflows, queue: max only queues runs with the same existing ${{ github.ref }} value. GitHub documents that scheduled runs use the default branch, while workflow_dispatch uses the branch or tag receiving the dispatch and may explicitly target another ref via gh workflow run --ref (event semantics, CLI behavior). Consequently, dispatching either workflow against another branch can overlap its scheduled/default-branch run; because these jobs mutate repository-wide issue state, this can produce duplicate comments or conflicting closes instead of queuing every run. Use a concurrency group that does not include the ref if all invocations must be serialized.
Useful? React with 👍 / 👎.
Fixes #151
Adds
queue: maxto the concurrency blocks ofclose-issues.ymlandcompliance-close.yml— the last two scheduled+dispatch workflows that run on this fork without it. Both share one group (workflow + ref; ref is always the default branch for schedule/dispatch) withcancel-in-progress: false, so a dispatch silently replaced a pending scheduled run.Mirrors the close-prs fix in #133 / PR #148. Both files re-validated as YAML;
cancel-in-progressstays literalfalse(no queue/cancel validation trap). Local pre-push hook ran lint + typecheck (36/36) clean.Need help on this PR? Tag
@codesmith-botwith what you need.