ci: set parallel_tests multiplier for all integration suites#2759
Conversation
WalkthroughIn 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@src/tasks/spec.rake`:
- Around line 96-98: Clamp the worker count used by num_procs_flag so it never
returns fewer than 1 worker. Update the num_procs_flag helper to compute the
non-macOS parallelism value safely and ensure the -n argument cannot expand to 0
on low-CPU runners; keep the existing RubyPlatform/darwin branching but force a
minimum of 1 for the nproc-based count.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 4a9caa16-3b03-41b6-830a-b48959c9697c
📒 Files selected for processing (1)
src/tasks/spec.rake
4654ea1 to
ad9bcd1
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@src/tasks/spec.rake`:
- Line 17: The SPEC task command in spec.rake is always appending the
parallel_rspec `-n` worker flag, which overrides any CI-provided parallel-tests
multiplier. Update the task-building logic around the parallel_rspec invocation
so `num_procs_flag` is only added when no override is already configured, or
derive the worker count from the existing multiplier instead. Use the spec task
setup and the `parallel_rspec` command string to locate the fix.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 5a873e6c-905c-4ebf-8565-3d8069849515
📒 Files selected for processing (1)
src/tasks/spec.rake
ad9bcd1 to
618c902
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@ci/pipeline.yml`:
- Line 315: The shared PARALLEL_TEST_MULTIPLY_PROCESSES anchor is set too low
for the intended concurrency cap. Update the anchored value in the pipeline
configuration from 0.6 to 0.8 so the integration jobs use 80% of CPU count, and
keep the change applied at the PARALLEL_TEST_MULTIPLY_PROCESSES anchor that is
referenced by the integration job definitions.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 842d672e-d5ae-4669-a5d2-68034350020b
📒 Files selected for processing (1)
ci/pipeline.yml
changing this in hopes of reducing contention on CI workers