-
-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Now building also jcstress-tests-all-20240222.jar 20220908.jar #1020
Conversation
Those are based on closest (which were actually that day last) commit hashes. junit tests are passing. In addtion shortened hash to 7 latters and uses jdk17 to tip
Thank you for creating a pull request!Please check out the information below if you have not made a pull request here before (or if you need a reminder how things work). Code Quality and Contributing GuidelinesIf you have not done so already, please familiarise yourself with our Contributing Guidelines and Code Of Conduct, even if you have contributed before. TestsGithub actions will run a set of jobs against your PR that will lint and unit test your changes. Keep an eye out for the results from these on the latest commit you submitted. For more information, please see our testing documentation. In order to run the advanced pipeline tests (executing a set of mock pipelines), it requires an admin to post |
and unified names of output jars
|
||
echo "Resetting repo back to master" | ||
git checkout master | ||
# 20240222 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the significance of that date? Is that a tag for a major version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I see it, there is no significance. Unluckily there is also no tag. Double unluckily jcstress tags extremely rarely:(
As described here: adoptium/aqa-tests#5261 ; the jcstres in aqavit have heavily unclear binaries to execute:
The getDepenencies is pulling jcstress-tests-all-20240222.jar'
https://github.com/adoptium/TKG/blob/master/scripts/getDependencies.pl#L182
in addition, it is pulling it from personal server
and
however, the https://github.com/adoptium/aqa-tests/blob/master/system/jcstress/playlist.xml
is using jcstress-tests-all-20220908.jar
Those are not base don any tag, nor hash. They will be reused in the cstress runner, so the https://github.com/adoptium/TKG/blob/master/scripts/getDependencies.pl#L182 and https://github.com/adoptium/aqa-tests/blob/master/system/jcstress/playlist.xml are in harmony.
I think first step will be to let the getDependencies.pl to download 20220908, and use that in playlist.xml. Then to bump them both to 20240222 (as this is quite fresh). There may come som if jdk 8/11/...22 swithc as is done with jtrregs. This is stil to be decided. For now, I wanted to prepare binareis to use.
Thanx for bringing it up. If you have any top level hints, dont hesitate to write them to #1016 and adoptium/aqa-tests#5261.
Actually.. any hints welcomed :) Thanx for eyball!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smlambert - I think I need your guidance here :-). Which version(s) of jcstress does the testing group need? I read the other issues but I'm still unsure...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as any builder, we need tip and latest release for sure. I heavily recommend to not get stick to latest release, as they are not fluently released, and to verify jcstress failure you have to try something newer, always, even tip from time to time. So A middle path is to pick up something known to be stable on the fly, and starting using that. 20240202 is pretty fresh, and known to be stable, so very good candidate.
We do not need a build from that date. We need/want to use tagged or released builds. In order to do that, we need to 'test' that an appropriately recent tagged build can run the test targets we have, without major errors. So indeed, please do not bother building untagged/untracked versions of jcstress. I do not have time to review this PR today as I am on 'personal time off'. Please do not rush into merging anything. There is all the time in the world to get things right and yet takes no time at all to do the wrong thing. |
This PR is not in rush for sure. Whatever we agree should be built, will be built. However I think tagged builds are not an option. jcstress team (read shade) tags somehow randomly, and last tag is pretty old. Also I doubt we wish to go with tip, as that can indeed change dramatically without warning. From that point of view the 20240222 is pretty good option as it is known to be stable and is really fresh. I was following adoptium/aqa-tests#5261 where you gave me green light, unluckily only during voice chat, and it literally says:
Which is what this PR is doing (tip was already there). If you reconsidered, it is ok and I will follow for sure, I do not have intentions to break anything, but I would like to have aqa-tests jcstress build on better foundation then on random jcstress-tests-all-20220908.jar which was downloaded ages ago and can no longer be recreated. (Or I have not found it). Generally it is good we had this conversation. I realised, that all above is valid also for JMH, and that jcstres palylist and/or https://github.com/adoptium/TKG/blob/master/scripts/getDependencies.xml have to be able to work - on demand only! - with jcstress tip, as that is waht jcstress people will always ask us to do first. No rush from me. Do not spoil your time off. You made yourself clear you wish to double check that, and I'm greatful for it. |
Looking to adoptium/aqa-tests#5278 (and seeing adoptium/aqa-tests#5270 work ok) This shold be building only 20240222, and lets say with "correct" name of |
Currently aqa-tests is grabing jcstress from personal server so this PR won't affect aqa-tests. I think 20240222 is enough ( no need to build 20220908.jar). What's the difference of building the jar with jdk17 and jdk11? Do we need both version? Once this is in we can update aqa-tests. |
Right and right. I will drop the 2022 version as the 2024 is already "iun production" (was not when I strarted thi sPR)
That appeared to be wrong assumption. I will swithc it all to jdk8.At least we will know, when jdk8 is not worthy anymore. |
Please double check the naming of main tarball. Where this is more aligned to how maven is generating the jars, current usage in adoptium is |
Not sure what do you mean switch it all to jdk8. The project mentioned |
Sorry, I overwrote. See the PR, I switched to 11. I ment 11. My wrong for that "typo"/ |
https://ci.adoptium.net/view/Dependencies/job/dependency_pipeline/1186/artifact/jcstress/ Are jcstress-0.16.jar, jcstress-20240222.jar, jcstress-d6a81c3.jar different? If not we don't need to keep all of them? Could you @judovana make the PR ready for review if it's ready? |
The linking follows all other ci-pipellines buildjobs.
The goal is to have predictable names for pernament links, and still haveing clear what is waht. The jcstress-20240222.jar is now very similar to jcstress-d6a81c3.jar because only few commits was added in meantime, but it is ill idea to have internal testing agasint tip. |
So jcstress.jar, jcstress-d6a81c3.jar and jcstress-tip.jar are same? For now I think tip, latest release, jcstress-20240222.jar are enough as long as the sha is provided. |
jdk11=$(readlink -f $(find ${jvm_dir} -maxdepth 1 | sort | grep -e java-11- -e jdk-11 | head -n 1)) | ||
jdk17=$(readlink -f $(find ${jvm_dir} -maxdepth 1 | sort | grep -e java-17- -e jdk-17 | head -n 1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We dont. I can drop it if you insists. But I'm 51:49 to keep it. It is good to list individual jDKS in buildroot. Especially in case, that something will nto honour JAVA_HOME, it will ebcome very usefull.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we missing Java 21 here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean miss java 21? The container have jdk8, jdk11, jdk17 and also jdk21 iirc. Jcsress since some 2023 needs at elast jdk11 to build with. I'm checking the hdk versiosn just for case the build goes wrong. I can check the 21 too if you wish.
the upstream is correctlysetting source/version/release javc flags so to build each version by different jdk was just candy on the top. Now all three jcstresses (latest release, tip, and "latest used by us" ) are built by jdk11. If you wish, I have no objections to build tip by soemthign newer. :) ty!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like you only need to check for the existence of 11+ in that case? It seems over kill to check for each LTS version...
no jcstress-d6a81c3.jar and jcstress-tip.jar are same, and then jcstress.jar anf (jcstress-0.16.jar as I wrote above. All other ci-tools are keeping this convention. So I would keep it. |
tyvm! for approve! |
@karianna any suggestion? |
@karianna Hello, can you reevaluate? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need @smlambert to confirm versions we want supported.
Yes, in absence of a stable release tag to build off of, we proceed with this approach. If jcstress begins to employ release tagging in future, we can adjust. |
Those are based on closest (which were actually that day last) commit hashes. junit tests are passing.
In addition shortened hash to 7 latters and uses jdk17 to tip
Should be fixing #1016