jcstress
jcstress copied to clipboard
openjdk
CODETOOLS-7903748 - jcstress: Test list should honor concurrency settings
This is extracting List<TestConfig> configs =prepareRunProgram(classes, tests);
with all he HW/switches setup to separated method and reusing it in -l mode
I'm aware of triplicated removal of -agentlib, and will clean it up as CODETOOLS-7903756 will progress.
-l now honours also verbose mode, in which it prints not just matching tests but all really run tests, and thus enabling much more easy determining of all tests
help adjusted.
Maybe I'm missing plain quick initial all tests metod now, but with artificial -c MAX it seems doing exactly that
Progress
- [x] Change must not contain extraneous whitespace
- [ ] Change must be properly reviewed (1 review required, with at least 1 Committer)
Issue
- CODETOOLS-7903748: jcstress: Test list should honor concurrency settings (Bug - P4)
Reviewers
- @matcdac (no known openjdk.org user name / role)
Reviewing
Using git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jcstress.git pull/149/head:pull/149
$ git checkout pull/149
Update a local copy of the PR:
$ git checkout pull/149
$ git pull https://git.openjdk.org/jcstress.git pull/149/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 149
View PR using the GUI difftool:
$ git pr show -t 149
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jcstress/pull/149.diff
Webrev
:wave: Welcome back jvanek! 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.
![bridgekeeper[bot] avatar](https://avatars.githubusercontent.com/u/41768318?v=4 "Published by a pub.dev verified publisher"){kind=small}
@judovana This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
7903748: jcstress: Test list should honor concurrency settings
Reviewed-by: shade
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 no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.
As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@shipilev) but any other Committer may sponsor as well.
➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).
@judovana Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.
Webrevs
- 11: Full - Incremental (02725da5)
- 10: Full - Incremental (514e285f)
- 09: Full - Incremental (f3858f3c)
- 08: Full - Incremental (48ab2a19)
- 07: Full - Incremental (9b1ab093)
- 06: Full - Incremental (4f455a99)
- 05: Full - Incremental (4ee850d8)
- 04: Full - Incremental (713c5a2d)
- 03: Full - Incremental (f4ac4222)
- 02: Full - Incremental (af53874c)
- 01: Full - Incremental (58455e2d)
- 00: Full (a52df414)
@judovana Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.
hi! Thanx a lot for review! I did as you bif, although I would prefer to keep LIST_OPTION_DESCRIPTION as it was - on two lines. Whether to use it in parser.accepts method or not, to have it outside is much better, but then it should be done globalluy. NVM:) Thanx again!
@judovana Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.
@judovana This pull request has not yet been marked as ready for integration.
@judovana This pull request has not yet been marked as ready for integration.
Hmm, then we need approver and sponsor?
@judovana This pull request has not yet been marked as ready for integration.
Hello my fellow colleague contributors @shipilev @mmirwaldt @pavelrappo @izeye @simonis @edvbld @isopov @lewurm ,
I had signed OCA around 9 years ago from the email id [email protected] , my only github account this one is also from the same email id [email protected] , I am subscribed to the mailing list jcstress-dev as well from the same email id [email protected] , could you let me know why OpenJDK GitHub is not recognizing my account, and shows as follows as highlighted in the image from above PR #149 ( https://github.com/openjdk/jcstress/pull/149 ) :-
seems to be a discrepancy between yellow circle (recognized, green tick) and red circle (Reviewers @matcdac : no known openjdk.org user name / role)
can anyone of you get this checked
also I need write / push and merge access
@matcdac, unfortunately I don't know your real name, so I can't check in the OpenJDK Census if you hold any kind of project role in the OpenJDK project. Notice that merely signing a OCA doesn't give you any project role - it only makes you an OpenJDK Contributor. Take a look at the OpenJDK projects page for details about how to advance from Contributor to Author, Committer and Reviewer.
Regarding the image you've attached - I don't think the information in the yellow and red circle contradict. The yellow circle is information from GitHub's builtin workflow. It means that you've successfully reviewed and approved this PR from GitHub's perspective. The information in the red circle comes from the OpenJDK project's customized GitHub workflow which additionally checks the OpenJDK role (according to the OpenJDK Census) of contributors.
After becoming an OpenJDK Author (which will give you an OpenJDK user name), you'll have to associate your GitHub account and your OpenJDK username in order for this workflow to recognize you with your OpenJDK role.
Yup, @matcdac would need to contribute two changes (or more) become an OpenJDK Author first, before they can receive write access to OpenJDK infrastructure (like the bug tracker, for example). Since they're not a Committer on the Code Tools Project, the review doesn't count towards meeting this requirement:
"Change must be properly reviewed (1 review required, with at least 1 Committer)"
That is unhappy situation:( Then both https://github.com/openjdk/jcstress/pull/149 https://github.com/openjdk/jcstress/pull/150 remain valid review of course. TY!
Sorry, I understood the Wait, let's make sure it passes the GHA tests, enable the workflows first, and then update the PR. that it will get enabled somehow on its own or by you.
I'm failing to see whre to enabel them as aprt of my PRs
@judovana Your change (at version 02725da5dd1e602cde195fd359e41e5da5d0e5d7) is now ready to be sponsored by a Committer.
Going to push as commit 164a3f58c290d1da8f3ec91f29f5d77b185043e4.
Since your change was applied there has been 1 commit pushed to the master branch:
- 6def1a9384321534dca92e147dbe5e573c9ec601: 7903756: jcstress: Skip debugging JVM options for sub-processes
Your commit was automatically rebased without conflicts.
@shipilev @judovana Pushed as commit 164a3f58c290d1da8f3ec91f29f5d77b185043e4.
:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.