skara
skara copied to clipboard
1626: 8-pool records not consumed by openjdk8uX fixversions
The logic for matching *-pool records in backports is not matching openjdk8uX to an issue with fixVersion 8-pool. The version parsing logic for OpenJDK releases is a bit of a minefield, where sometimes the prefix is relevant and sometimes not. This fix isolates ignoring of the prefix to just matching of *-pool records in Backports.java. I'm reusing the same regex that already existed for doing something similar in that class. The previous usage was in the logic for the hgupdate-sync label.
I don't think this will introduce any unwanted behavior, but I would appreciate if someone else could help think it through.
I chose to prioritize exact *-pool matches and fallback to matching just the numeric part of the feature version. This means that if we decided to add openjdk8-pool as a pool version in the future, that would continue to work.
Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
- [x] Change must not contain extraneous whitespace
Issue
- SKARA-1626: 8-pool records not consumed by openjdk8uX fixversions
Reviewing
Using git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/skara pull/1389/head:pull/1389
$ git checkout pull/1389
Update a local copy of the PR:
$ git checkout pull/1389
$ git pull https://git.openjdk.org/skara pull/1389/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1389
View PR using the GUI difftool:
$ git pr show -t 1389
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/skara/pull/1389.diff
:wave: Welcome back erikj! A progress list of the required criteria for merging this PR into master
will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.
Yeah, this is a minefield 😨 I can't say that your change is obviously correct, but at least the existing tests and your new test is passing and the newly added logic corresponds to your reasoning. But whether that is the end of OpenJDK version parsing is hard to say 🤷
@erikj79 This change now passes all automated pre-integration checks.
ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.
:mag: One or more changes in this pull request modifies files in areas of the source code that often require two reviewers. Please consider if this is the case for this pull request, and if so, await a second reviewer to approve this pull request before you integrate it.
After integration, the commit message for the final commit will be:
1626: 8-pool records not consumed by openjdk8uX fixversions
Reviewed-by: ehelin
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.
At the time when this comment was updated there had been 8 new commits pushed to the master
branch:
- b7b4d114a01cb703f35450ffe4820ce047fd235b: 1616: Improve error message when an author isn't found in GitLab
- 32a07238fde7773d64f0330e76d77f8d5d44f82a: 1603: Make labels handling consistent in all Issue implementations
- ae79322ae8dd6ce91e00d46f84139020e3b55f90: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed
- 522d894fded2cf99b88d7873de5b69faed161cd4: 1215: Clean label not updating correctly
- b061577e3ed45b464e73b865d8b73528b9166e07: 1612: Temp workaround GitLab returning 500 when modifying labels
- a6860bcba94d93a2be7429ad7a8766755a925581: 1364: Jira Issues should be resolved as "Fixed"
- 773ec06c2a813f03d4341cf4ae36f9c5ae12fd70: 327: git webrev: Print the location of the generated webrev upon successful completion
- 7cf47ca037f9157195d330d746ffd7164edffea2: 1512: MirrorBot may get stuck failing to clone repository
Please see this link for an up-to-date comparison between the source branch of this pull request and the master
branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
➡️ To integrate this PR with the above commit message to the master
branch, type /integrate in a new comment.
/integrate
Going to push as commit 68b4f58708ef4c113a81ce38455192a692f4c86b.
Since your change was applied there have been 9 commits pushed to the master
branch:
- 4b40646da7589e3dd88e34d00112bddc3dd1428b: 1606: PullRequestPoller always processes the last updated MR for GitLab
- b7b4d114a01cb703f35450ffe4820ce047fd235b: 1616: Improve error message when an author isn't found in GitLab
- 32a07238fde7773d64f0330e76d77f8d5d44f82a: 1603: Make labels handling consistent in all Issue implementations
- ae79322ae8dd6ce91e00d46f84139020e3b55f90: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed
- 522d894fded2cf99b88d7873de5b69faed161cd4: 1215: Clean label not updating correctly
- b061577e3ed45b464e73b865d8b73528b9166e07: 1612: Temp workaround GitLab returning 500 when modifying labels
- a6860bcba94d93a2be7429ad7a8766755a925581: 1364: Jira Issues should be resolved as "Fixed"
- 773ec06c2a813f03d4341cf4ae36f9c5ae12fd70: 327: git webrev: Print the location of the generated webrev upon successful completion
- 7cf47ca037f9157195d330d746ffd7164edffea2: 1512: MirrorBot may get stuck failing to clone repository
Your commit was automatically rebased without conflicts.
@erikj79 Pushed as commit 68b4f58708ef4c113a81ce38455192a692f4c86b.
:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.