Update Java versions to latest releases - #898
Open
azure-pipelines[bot] wants to merge 4 commits into
Open
Conversation
Auto-detected new Java versions from Microsoft OpenJDK releases. This PR was automatically generated by the Java version check pipeline. Pipeline Run: 20260907.1
Contributor
Author
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
The pipeline cuts a new PR every Monday even when nothing has changed. Seven are open right now and all seven propose the same JDK 11/17/21/25 bump, differing only in JDK 8. Two things caused it. The branch name carried a timestamp, so the "does a PR already exist?" lookup asked about a branch that had just been created and always came back empty. And change detection only compared against dev, which never moves while the previous PR sits unmerged, so the same bump looked new every week. Now there is one long lived branch, automated/update-java-versions, that gets refreshed in place. The run also compares against that branch, not just dev, and does nothing at all when it already carries the same versions. If the versions really did move, the branch is reset onto dev and force pushed so the PR stays a single clean commit, and the existing PR is updated instead of a new one being opened. Two edge cases that used to get stuck now resolve on their own. A closed PR whose branch is still around gets reopened rather than skipped. And if the create call comes back 422 because something else opened the PR in the meantime, the run adopts that PR and updates it instead of failing with the branch already pushed. Also replaced the grep based JSON handling with python, which this job already runs for the merge step. Counting occurrences of "number" in raw JSON is fragile because nested objects such as milestones carry one too. Added a label and a hidden marker in the body so the PR can still be found if the branch name ever changes again.
This was referenced Sep 9, 2026
Contributor
|
/azp run |
Contributor
Author
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Ahmed Muhsin (ahmedmuhsin)
previously approved these changes
Sep 9, 2026
added 2 commits
September 9, 2026 13:21
The bare --force-with-lease form only works when the remote's fetch refspec maps the bot branch into refs/remotes/origin. It does not always, and when it does not the push is rejected with "stale info". That would have hit the refresh path, so the first run that found newer JDKs than the open PR would have failed after committing but before updating it. Capturing the remote SHA at fetch time and passing it as an explicit lease value works either way and keeps the same protection. Caught while porting this fix to the Docker repo, where the clone is single-branch and the failure reproduces every time.
Deduplicating the weekly PR made the pipeline quieter, but the duplicates had been doing a job: a fresh PR every Monday kept the update in people's faces. Without them a PR can sit unnoticed, which is exactly what happened in the Docker repo where one went unread for two months. So every run that finds a PR already open now comments on it, tagging whoever is currently requested for review and saying how long it has been waiting. The mentions come from the requested-reviewers API rather than a hardcoded list, so they follow CODEOWNERS instead of drifting from it. Three cases. Nothing new and the PR still current: nudge to review it. Newer JDKs found: refresh the PR and say so in the same comment. Nothing new and dev has moved on: say the PR looks redundant and ask for it to be merged or closed. Creating a PR stays silent, since that notifies on its own. This means the step now runs on quiet weeks too, so the HasChanges condition is gone and the change detection reports state instead of exiting early. Dropping the explicit condition restores the default succeeded(), so it is still skipped if the previous step fails.
Contributor
|
/azp run |
Contributor
Author
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Ahmed Muhsin (ahmedmuhsin)
approved these changes
Sep 9, 2026
Tsuyoshi Ushio (TsuyoshiUshio)
approved these changes
Sep 9, 2026
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
2 participants
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.
Weekly JDK bump, plus a fix to the pipeline that generates it.
The version check pipeline opened a new PR every Monday even when nothing had changed. Seven were open, all proposing the same JDK 11/17/21/25 values. Two causes: the branch name carried a timestamp, so the "does a PR already exist?" lookup queried a branch created seconds earlier and never matched, and change detection only compared against
dev, which never moves while the previous PR sits unmerged.Now there is one long lived branch,
automated/update-java-versions, refreshed in place. The run compares against that branch as well asdevand does nothing when it already carries the same versions. Otherwise it resets ontodev, force pushes, and updates the existing PR rather than opening another. A closed PR whose branch is still around gets reopened, and a 422 from the create call adopts the PR that beat it instead of failing.Superseded PRs #882, #887, #892, #894, #896 and #897 are closed, along with 16 stale branches.
Worth flagging for review: this pipeline sets
pr: none, so CI cannot exercise the change. It was verified locally by running the extracted steps against throwaway git repos with a stubbed GitHub API, and by replaying the duplicate scenario against the old code to confirm it reproduces.