ci: improve workflows#2288
Conversation
commit: |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2288 +/- ##
=======================================
Coverage 32.61% 32.61%
=======================================
Files 7 7
Lines 371 371
Branches 131 131
=======================================
Hits 121 121
Misses 194 194
Partials 56 56 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This reverts commit 64703da.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughGitHub Actions workflows now define concurrency behavior for CI and nightly releases. Checkout steps disable persisted credentials, the lint job uses the Node.js 24 release line, and selected jobs run on Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 55-56: Update the actions/checkout step in the changes job to set
persist-credentials to false, matching the hardened checkout configuration used
elsewhere in the workflow.
In @.github/workflows/release-nightly.yml:
- Around line 13-15: Update the workflow’s concurrency configuration to set the
pending-run queue behavior to max, preserving cancel-in-progress: false, so all
nightly release events are retained and processed sequentially in FIFO order.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 0eb1dd76-1901-44b3-9d51-339741b76c84
📒 Files selected for processing (4)
.github/workflows/agent-scan.yml.github/workflows/ci.yml.github/workflows/release-nightly.yml.github/workflows/reproduction-close.yml
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.event.number || github.ref }} | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Workflow file:\n'
if [ -f .github/workflows/release-nightly.yml ]; then
cat -n .github/workflows/release-nightly.yml | sed -n '1,80p'
else
echo 'missing'
fi
printf '\nOther workflow concurrency snippets:\n'
rg -n "concurrency:|queue:|cancel-in-progress:" .github/workflows || true
printf '\nCurrent workflow trigger summary:\n'
python3 - <<'PY'
from pathlib import Path
p=Path('.github/workflows/release-nightly.yml')
if not p.exists():
print('missing')
raise SystemExit
for i,line in enumerate(p.read_text().splitlines(),1):
if i<=40 and any(s in line for s in ['on:', 'workflow_dispatch', 'push', 'schedule', 'concurrency']):
print(f'{i}: {line}')
PYRepository: nuxt/image
Length of output: 3118
🌐 Web query:
GitHub Actions concurrency queue max behavior pending runs cancel-in-progress false
💡 Result:
In GitHub Actions, the behavior of a concurrency group when cancel-in-progress is false depends entirely on whether you are using the default single-queue behavior or the recently introduced extended queuing capability [1][2]. Default Behavior (Implicit queue: single) When you set cancel-in-progress: false (or omit it, as it defaults to false), GitHub Actions allows at most one job or workflow to be running and one to be in a pending state [1][3]. - If a new run is triggered while one is already running, it becomes the single pending run [3][4]. - If a subsequent (third) run is triggered while another is already pending, the existing pending run is canceled and replaced by the new run [1][4]. - This ensures that only the most recently triggered run is waiting to execute next, while the currently running job completes [4]. Extended Queuing Behavior (queue: max) As of May 2026, you can opt into a larger queue by setting queue: max in your concurrency block [2]. - This allows up to 100 jobs or workflow runs to be queued in a pending state within the same concurrency group [1][5]. - Runs are processed sequentially in the order they were queued [1][2]. - When the queue reaches its limit of 100, any additional incoming runs are canceled [1][5]. Important Constraints - You cannot combine queue: max with cancel-in-progress: true; doing so will result in a workflow validation error because they represent conflicting strategies for handling concurrent runs [1][6]. - The default behavior (queue: single) is essentially a queue of size 1 where new entries force the eviction of older ones [1][4]. The queue: max option allows for a true first-in-first-out (FIFO) queue for up to 100 items [1][2].
Citations:
- 1: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/control-the-concurrency-of-workflows-and-jobs
- 2: https://github.blog/changelog/2026-05-07-github-actions-concurrency-groups-now-allow-larger-queues/
- 3: Clarify concurrency cancel-in-progress behaviour github/docs#30647
- 4: https://stackoverflow.com/questions/76096372/how-to-queue-more-than-one-github-action-workflow-run
- 5: https://docs.github.com/en/actions/reference/limits
- 6: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
Queue pending nightly releases sequentially.
With cancel-in-progress: false, GitHub Actions still defaults to a single pending run, so a burst of pushes can drop earlier nightly release events. Add queue: max if every release event should be processed in FIFO order.
Suggested configuration
concurrency:
group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.event.number || github.ref }}
cancel-in-progress: false
+ queue: max📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| concurrency: | |
| group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.event.number || github.ref }} | |
| cancel-in-progress: false | |
| concurrency: | |
| group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.event.number || github.ref }} | |
| cancel-in-progress: false | |
| queue: max |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release-nightly.yml around lines 13 - 15, Update the
workflow’s concurrency configuration to set the pending-run queue behavior to
max, preserving cancel-in-progress: false, so all nightly release events are
retained and processed sequentially in FIFO order.
There was a problem hiding this comment.
This is probably a question for @danielroe, is it ok if nightly releases get dropped as long as the latest one is ok, or should all be published?
2 participants
🔗 Linked issue
📚 Description
Hi, there are a few improvements that can be made to the workflows.
ubuntu-slimrunnerUse
ubuntu-slimforagent-scan.yml,reproduction.-close.ymland some inci.yml. The runner readme provides more info about the tools and the blog post gives some potential use cases.persist-credentials: falseUse
persist-credentials: falseon everyactions/checkoutinci.yml(none of the jobs perform subsequent git operations). See usage for more info.Concurrency
Add
concurrencyto the PR-triggered workflows so a new push cancels the previous in-flight run of the same workflow.release-nightly.ymluses thecancel-in-progress: falseas to not interrupt the release. Instead, it will queue the next release.Related