-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
Add shaInfo target to collect all shas after the test run #651
base: master
Are you sure you want to change the base?
Conversation
This is a nice way to handle test material that is pulled in via Separately we will need to think about how to deal with test material that is precompiled and run from jar files (such as dacapo and renaissance). We need to check with others who use AQAvit before removing the ant macro, in case it is in use by anyone for internal vendor test material. |
Have to work with adoptium/aqa-tests#5819 |
settings.mk
Outdated
@@ -364,7 +364,7 @@ $(SUBDIRS_TESTTARGET): | |||
|
|||
$(TESTTARGET): $(SUBDIRS_TESTTARGET) | |||
|
|||
_$(TESTTARGET): setup_$(TESTTARGET) rmResultFile $(TESTTARGET) resultsSummary teardown_$(TESTTARGET) | |||
_$(TESTTARGET): setup_$(TESTTARGET) rmResultFile $(TESTTARGET) shaInfor resultsSummary teardown_$(TESTTARGET) |
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.
- Does it make sense to have
shaInfor
before running the test? In the event of a crash, we will still retain the SHA information. - Could we rename
shaInfor
toshaInfo
?
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 can be done right after make compile. https://ci.adoptium.net/view/Test_grinder/job/Grinder/12117/ https://ci.adoptium.net/view/Test_grinder/job/Grinder/12118/
However it depends on what the crash is. If the crash exit the job instantly ( https://ci.adoptium.net/view/Test_grinder/job/Grinder/12124/console, this is not a test crash, still explain the scenario) , SHAs.txt is available but *.tap file unavailable, which won't help jenkins story unless we also archive it.
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.
Updated to shaInfo
I do not see openj9 SHA in your Grinder. |
SHA will be collected only if the REPO is used. That is say for openj9 if you run openj9 tests, the sha will be there. My grinder is testing functional.dev and sanity.perf, which doesn't include openj9 tests. The reason for choosing those two categories is currently the SHAs for those two categories are missing. Similar to grinder if running openjdk tests against impl=hotspot there will be no openj9 repo SHA. |
Openj9 sha was not captured even if we ran test in openj9 repo.
https://ci.adoptium.net/view/Test_grinder/job/Grinder/12101/console |
openj9 repo is removed once the material is moved https://github.com/adoptium/aqa-tests/blob/master/get.sh#L664, similar to vendors repo information. Hence no .git and no sha information. Those information is still available by testenv.properties, which can be combined to SHAs.txt. Or it's not necessary to remove those repo the workspace will be deleted for jenkins run. https://ci.adoptium.net/view/Test_grinder/job/Grinder/12113/ - dynamic compile |
I'm also thinking if the testenv.properties is necessary with *.tap get all SHAs information though it's a separate issue I will take a look later. |
From a 'secure dev' perspective, if we are using anything from the a repo, even if its a makefile or a variable or two are set because of it (https://github.com/eclipse-openj9/openj9/blob/master/test/functional/testVars.mk), we should keep track the repo and the SHAs. What we ultimately want to be able to do is to fully reproduce a test run down to every detail. |
See https://github.com/adoptium/aqa-tests/pull/5819/files, which won't remove openj9 or vendor's repo. So all SHAs can be collected by shaInfo targets https://ci.adoptium.net/view/Test_grinder/job/Grinder/12113/ - dynamic compile Alternatively is for openj9 and vendors repos call getSHAs.sh in get.sh as before. I personally would prefer the first solution to keep the process simple and well maintained. Changes for both solutions will be in aqa-tests repo. This PR won't be affected. |
We work with multiple vendor repos (5 vendor repos and soon to be 6). Leaving unused material in the workspace can create confusion. |
All vendors repos are cloned to its own destination https://github.com/adoptium/aqa-tests/blob/master/get.sh#L719 I'm not sure why it causes confusion. I don't mind keep removing them if this is preferred. PR adoptium/aqa-tests#5819 updated. https://ci.adoptium.net/view/Test_grinder/job/Grinder/12131/ |
Part of adoptium/aqa-tests#5818