Retry Maven Central flakes when building the release jars - #5500
Merged
Conversation
The release-jars job builds the ParparVM JavaAPI and ByteCodeTranslator jars and attaches them to the published GitHub release. It called mvn bare, so a single transient Maven Central 403/429 from the runner CDN edge killed it at plugin resolution, ~30s in, before compiling anything. That is what happened on 7.0.264: maven-compiler-plugin:3.11.0 came back 429 Too Many Requests, the job failed, and the release published without its two jars -- every release from 7.0.261 on had them. The job only runs on release-published events, so it fails rarely, silently, and precisely when it matters. (7.0.264's assets have since been restored by re-running the job.) The sibling vm-tests job already worked around the same flake with an inline retry helper. Lift that into scripts/ci/retry.sh, alongside the existing scripts/ci/apt-get-update.sh, and use it from both jobs so the release path gets the protection the test path already had. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 70f2628bd8
ℹ️ 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".
…nges Two review findings from the Codex pass: RETRY_ATTEMPTS=0 or a non-numeric value made `seq` emit nothing (GNU) or error, the loop body never ran, `status` stayed 0, and the wrapper exited successfully *without ever running the command* -- the worst possible failure for a release-jars guard, and a direct contradiction of the script's own "always attempted at least once" contract. Both overrides are now validated as integers and rejected with exit 2, consistent with the existing no-command usage error; these are set in workflow YAML, so a typo should be loud rather than silently clamped. While confirming it: BSD and GNU seq disagree on degenerate ranges (`seq 1 0` yields nothing on GNU but "1 0" on BSD, so attempts=0 ran the command twice on macOS and zero times in CI). Replaced with an arithmetic while-loop, which runs the body exactly `attempts` times on both. Also added scripts/ci/retry.sh to this workflow's pull_request and push path filters, so a future change to the helper actually exercises the jobs that consume it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Contributor
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happened
Run 30594669157 (release 7.0.264) failed the
release-jarsjob 30s in:A transient Maven Central 429 from the runner CDN edge, at plugin resolution, before anything compiled. The job's last step attaches the ParparVM jars to the published release, so it never ran and 7.0.264 shipped without them — every release since 7.0.261 has
ByteCodeTranslator-1.0-SNAPSHOT.jarandJavaAPI-1.0-SNAPSHOT.jar, 7.0.264 had only the guide and javadocs. Anything fetchingreleases/latest/download/...for those jars got a 404.The sibling
vm-testsjob on the same run passed — it already retries this exact flake (added for the 403 variant).release-jarscalledmvnbare.This job only runs on release-published events, so it fails rarely, silently, and exactly when it matters.
The change
Lift the inline retry out of
vm-testsintoscripts/ci/retry.sh, next to the existingscripts/ci/apt-get-update.sh, and use it from both jobs. Bounded at 3 attempts / 30s, overridable viaRETRY_ATTEMPTSandRETRY_DELAY_SECONDS; the last attempt's exit status propagates. A real build failure fails identically on every attempt, so retrying only costs time on a genuinely broken build.Verified locally: success passes through, a flaky command succeeds on attempt 2, a hard failure exits with the command's own status (7), a missing command exits 127, and no arguments exits 2.
Already done separately
7.0.264's assets were restored by re-running the failed job — the release page now carries both jars again. This PR is only about it not recurring.
Noted, not fixed here
softprops/action-gh-release@v1in this job targets the deprecated Node 20 runtime (warning on the successful rerun). Same failure class — if it breaks, a release silently ships without jars — but av1→v2bump is its own change.HeavyLoadBenchmarkTestlogsWARNING: Failed to compile HelloCodenameOneon every run and continues: it compilesscripts/hellocodenameonewith JDK 8, but that source is Java 17 (records, switch expressions, text blocks). The benchmark has never included the app payload it intends to. Pre-existing and unrelated to the release failure.🤖 Generated with Claude Code