SONARJAVA-6216 Optimize CI to reduce Repox bandwidth for sonar-java: add timeouts#5539
Conversation
Applied automated safe optimizations to reduce Repox bandwidth consumption. See PR description for details of changes and additional recommendations. Generated by jfrog-optimizer plugin
tomasz-tylenda-sonarsource
added
the
automated-ci-optimization
hashicorp-vault-sonar-prod
bot
changed the title
tomasz-tylenda-sonarsource
changed the title
|
I manually undid |
tomasz-tylenda-sonarsource
changed the title
tomasz-tylenda-sonarsource
changed the title
SummaryThis PR applies two safe, operational improvements across GitHub Actions workflows:
Not included: The PR description mentions recommended changes (Maven cache rotation, SNAPSHOT gating, JDK caching, workflow_run sequencing), but those are deferred to future work. The What reviewers should knowScope is smaller than the description suggests — verify you're only reviewing timeouts + concurrency, not the larger optimization proposals mentioned in the recommendation section. Where to verify:
What reviewers should check:
No cache behavior change, no build speedup expected — these are reliability/resource-waste improvements, not bandwidth reduction. The recommended optimizations in the description are future work.
|
|
![sonar-review-alpha[bot]](https://avatars.githubusercontent.com/in/3025063?s=60&v=4){kind=small}
| types: ["review_requested"] | ||
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} |
There was a problem hiding this comment.
Bug: cancel-in-progress: true with a per-PR concurrency group is unsafe for a review_requested trigger.
GitHub fires one review_requested event per reviewer added. If two reviewers are requested in quick succession (or as a batch), both runs land in the same concurrency group (workflow-pr_number), so the second run cancels the first mid-flight. Whatever this workflow does for the first reviewer (Jira transition, notification, etc.) is silently abandoned.
cancel-in-progress is appropriate when only the latest run matters (e.g. a lint check on every push). For event-driven workflows where each event represents a distinct real-world action, it loses data.
Either drop cancel-in-progress: true, or scope the group to the specific reviewer so concurrent runs for different reviewers don't collide:
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number }}-${{ github.event.requested_reviewer.login || github.event.requested_team.slug }}
cancel-in-progress: true| types: ["review_requested"] | |
| concurrency: | |
| group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} | |
| concurrency: | |
| group: ${{ github.workflow }}-${{ github.event.pull_request.number }}-${{ github.event.requested_reviewer.login || github.event.requested_team.slug }} | |
| cancel-in-progress: true | |
- Mark as noise
1 participant
Summary
Automated CI optimization to reduce JFrog Artifactory (Repox) bandwidth usage.
Jira: BUILD-XXXXX
Anomaly detected: no-data — info
Current bandwidth: N/A GB/week (vs N/A GB/week average)
Week-over-week change: N/A
Estimated savings: ~3-5 builds/week avoided + reliability improvements
Applied Changes (safe, low-risk)
Recommended Changes (manual review needed)
1. Maven Cache Key Rotation
File: build.yml, dogfood.yml, unified-dogfooding.yml, release.yml, automated-release.yml
Issue: Cache keys embed commit hash, causing ~6 distinct keys per 5 runs with no cache reuse.
Suggestion:
Risk: Low (cache behavior is well-understood; may need coordination with composite actions in SonarSource/ci-github-actions)
Estimated Impact: ~30-50 GB/week
2. Volatile Matrix Gating
File: build.yml, automated-release.yml, PrepareNextIteration.yml
Issue: 3 workflows reference DEV/SNAPSHOT versions without nightly_only guard. 61 SNAPSHOT dependencies force re-resolution every build (~46 downloads per job).
Suggestion:
Risk: Low-Medium (requires testing with nightly schedule; may need to add override label for on-demand full builds)
Estimated Impact: ~10-20 GB/week
3. JDK Caching
File: build.yml, dogfood.yml, unified-dogfooding.yml
Issue: 46 Repox JDK downloads per build job; JDK is not cached.
Suggestion:
Risk: Low
Estimated Impact: ~5-10 GB/week
4. Workflow_run Sequencing
File: automated-release.yml
Issue: Runs in parallel with build.yml push trigger, missing cache warmup opportunity.
Suggestion: Switch to
workflow_runtrigger to wait for build cache warmup before starting release jobs.Risk: Low-Medium (requires testing; may introduce sequential delay but ensures cache hits)
Estimated Impact: ~5-10 GB/week
How to Verify
Verification Checklist
References