Repository navigation
Conversation
Co-authored-by: Codesmith <codesmith-bot@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (3)
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review. WalkthroughFour CI workflow jobs now use runners with increased CPU capacity. The workflows retain their other settings. ChangesCI runner capacity
Priority: ⬇️ Low Change: Other Merge Risk: ⚪ Minimal · up to The selected CI jobs gain compute capacity at the reported roughly $5/month increase. No actionable workflow or scheduling issue is established, so no concrete merge-blocking risk remains. 🚥 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 |
Moves four CPU-bound jobs to larger Blacksmith runners, selected from the right-sizing recommendations for this repo (last 7 days of runs). Each one keeps all of its cores busy during its heavy phases, so more vCPUs should shorten it. Combined estimated cost impact is about +$5/month.
Apply for speed
Async Runner Jobs / Async Runner Build (
runner.yml):blacksmith-2vcpu-ubuntu-2404→blacksmith-4vcpu-ubuntu-2404High confidence. The Rust release build and tests pin both cores: in the busiest runs, average CPU is 90% and 86% of the run is spent above 80% CPU. Runtime is 3m01s at p50 and 4m27s at p95 across 48 runs (about 230 runs/month). Estimated cost impact: +$0.53/month. Sample run metrics
CodeQL / Analyze (javascript) (
codeql.yml):blacksmith-4vcpu-ubuntu-2404→blacksmith-8vcpu-ubuntu-2404Medium confidence. All 4 cores are busy at the job's peak (95th percentile CPU 99%), and the busiest runs spend 36% of their time above 80% CPU. Peak memory reaches 62%; the 8 vCPU runner also doubles memory.
javascriptis the matrix's only leg, so the sharedruns-onchanges directly. Runtime is 1m22s at p50 and 2m03s at p95 across 54 runs (about 259 runs/month). Estimated cost impact: +$2.80/month. Sample run metricsDocker Build & Publish (Dev) / Build & Push Backend (Dev) - linux/arm64 (
docker-dev.yml):blacksmith-4vcpu-ubuntu-2404-arm→blacksmith-8vcpu-ubuntu-2404-armMedium confidence. Full builds use all 4 cores (95th percentile CPU 98%, with the busiest runs spending 24% of their time above 80% CPU). Half the runs finish in about 30s (likely cached builds), so the gain lands on the slower rebuilds: p95 is 6m39s across 33 runs (about 158 runs/month). This leg is also the slower of the two Backend legs that the manifest job waits on. Estimated cost impact: +$1.46/month. Sample run metrics
Docker Build & Publish (Dev) / Build & Push Async Runner (Dev) - linux/arm64 (
docker-dev.yml):blacksmith-4vcpu-ubuntu-2404-arm→blacksmith-8vcpu-ubuntu-2404-armMedium confidence. Strongly CPU-bound: in the busiest runs, average CPU is 69% and 59% of the run is spent above 80% CPU across all 4 cores. Runtime is 29s at p50 and 2m36s at p95 across 33 runs (about 158 runs/month). Estimated cost impact: +$0.40/month. Sample run metrics
Both Docker rows change only the
linux/arm64entry of their job's matrixinclude. Thelinux/amd64legs and the Frontend v2 and MCP jobs keep their current runners:Check names stay the same because they're built from
matrix.platform. The Composer cache key usesmatrix.cache-key, so it doesn't depend on the runner label either.docker-dev.ymlonly runs on pushes todevelopand manual dispatch, so this PR's checks only exercise therunner.ymlandcodeql.ymlchanges. The Docker legs pick up the new runners once this lands ondevelop.Summary by CodeRabbit