Skip to content
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

Test headless components #5084

Merged
merged 36 commits into from
Feb 28, 2024
Merged

Conversation

andrlos
Copy link
Contributor

@andrlos andrlos commented Feb 21, 2024

err first of all - please ignore the number of commits and if this gets merged, please squash them into one..

this is an attempt of contributing testHeadlessComponents suite into aqa-vit functional tests.

I managed to get a green grinder run for this -> https://ci.adoptium.net/view/Test_grinder/job/Grinder/8902/ .
While I still suspect there is something off with the jtr.xml reports not being correctly propagated to artifacts I believe this can be resolved swiftly in a broader discussion, hence this PR.

This will solve #4875 .

Cheers!

Copy link
Contributor

@smlambert smlambert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @andrlos - I have added some comments and we will also want to run Grinders for these tests against all platforms/versions to which they apply.

functional/testHeadlessComponents/playlist.xml Outdated Show resolved Hide resolved
functional/testHeadlessComponents/README.md Outdated Show resolved Hide resolved
BOOTJDK_ARCHIVE_DIR - in case the user wants to use arbitrary jdk build, he can provide path to its archive and it will be used in jre execution. Creates $WORKSPACE/bootjdkarchive and downloads latest temurin archive if not set.
WORKSPACE - directory where the testsuite is going to execute all the tests. ~/workspace by default
TMPRESULTS - this is a location where the logfiles will be after the testsuite finishes. Same as WORKSPACE by default.
*JREJDK - This tells the testsuite whether we are testing jre or jdk.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AQAvit has a USE_JRE parameter that could be leveraged, but won't block this PR regarding its use.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh talking about parameters.. is there anything saying whether the testmachine has a display output? we could use it to enable a few more testscases via XDISPLAY variable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We set XDISPLAY via the Xvfb Jenkins plugin in our test pipeline code here: https://github.com/adoptium/aqa-tests/blob/master/buildenv/jenkins/JenkinsfileBase#L735-L757 (exceptions for AIX and solaris platforms, where Xvfb plugin does not work, those are set without the plugin as shown in that code snippet).

So, machines at this Jenkins server (ci.adoptium.net) have capability for XDISPLAY.

I should note that for a couple of our Temurin distributions, we only produce a headless build (alpine-linux and riscv). I presume these testcases are still valid against them, but will double-check via Grinders that they run as expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and how does the USE_JRE parameter work(what are the possible values)? I need to have JREJDK filled either with a value of "jre" or "jdk" so it knows what kind of behavior it can expect.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

USE_JRE is an environment variable, that if set to true, means we TEST_JDK_HOME (the binary that we want to test) to the JRE (rather than the JDK) so that particular tests are run with the JRE rather than the JDK that we pick up

I am happy to bring this PR in as it stands and come back with a follow-up as needed (once we think this through more thoroughly... my worry is whether some vendors do not produce JREs for later versions of Java, you'll still will want to check at the test level whether its available or not).

functional/testHeadlessComponents/build.xml Outdated Show resolved Hide resolved
functional/testHeadlessComponents/test.properties Outdated Show resolved Hide resolved
@andrlos
Copy link
Contributor Author

andrlos commented Feb 22, 2024

okay, I fixed majority of the mentioned lines, now I just need an answer about the USE_JRE variable adoptium uses.. also added separate commit to limit only on linux, windows and macs.. would have to test and add other platforms to allowed platforms first

@andrlos
Copy link
Contributor Author

andrlos commented Feb 22, 2024

huh totally forgot about the mac problem I had since my script uses "declare -A" <- associative array if I remember correctly.. which is not available on mac since the shell it uses is different.. it is either installable by homebrew or I would have to adjust the script heavily.. will have a look at this over the weekend :-)
The second failure is connected to windows which I will address with my buddy Radek on Monday.

@smlambert
Copy link
Contributor

For others awareness, a bunch of Grinders were kicked off for this new test against various platforms, see Grinders 8918 through to 8924 as some examples.

See a couple of failures there that warrant investigation, in Grinder/8922 mac machine may have an older version of declare that does not appear to support -A option

13:23:20  + declare -A resArray
13:23:20  /Users/jenkins/workspace/Grinder/aqa-tests/TKG/../functional/testHeadlessComponents/TestHeadlessComponents/testHeadlessComponents.sh: line 187: declare: -A: invalid option
13:23:20  declare: usage: declare [-afFirtx] [-p] [name[=value] ...]

In Grinder/8923, Windows run,

13:23:50  TESTING:
13:23:50  + set -e
13:23:50  + set -o pipefail
13:23:50  + SCRIPT_SOURCE='C:/jenkins/workspace/Grinder/aqa-tests/\functional\testHeadlessComponents\TestHeadlessComponents\testHeadlessComponents.sh'
13:23:50  + '[' -h 'C:/jenkins/workspace/Grinder/aqa-tests/\functional\testHeadlessComponents\TestHeadlessComponents\testHeadlessComponents.sh' ']'
13:23:50  +++ dirname 'C:/jenkins/workspace/Grinder/aqa-tests/\functional\testHeadlessComponents\TestHeadlessComponents\testHeadlessComponents.sh'
13:23:50  ++ cd -P 'C:/jenkins/workspace/Grinder/aqa-tests/\functional\testHeadlessComponents\TestHeadlessComponents'
13:23:50  ++ pwd
13:23:50  + readonly SCRIPT_DIR=/cygdrive/c/jenkins/workspace/Grinder/aqa-tests/functional/testHeadlessComponents/TestHeadlessComponents
13:23:50  + SCRIPT_DIR=/cygdrive/c/jenkins/workspace/Grinder/aqa-tests/functional/testHeadlessComponents/TestHeadlessComponents
13:23:50  ++ uname
13:23:50  + platform=CYGWIN_NT-10.0-20348
13:23:50  + '[' CYGWIN_NT-10.0-20348 == Linux ']'
13:23:50  + '[' CYGWIN_NT-10.0-20348 == Darwin ']'
13:23:50  + '[' CYGWIN_NT-10.0-20348 '!=' CYGWIN_NT-10.0-20348 ']'
13:23:50  + echo 'Unsupported platform'
13:23:50  Unsupported platform
13:23:50  + exit 1
13:23:50  -----------------------------------
13:23:50  TestHeadlessComponents_0_FAILED
13:23:50  -----------------------------------

@smlambert
Copy link
Contributor

Great, just saw your comment @andrlos after posting mine. No rush on this, there is great progress. The other platforms looked good, so I am not sure you would need to restrict to the 3 main ones (as you have done in the latest version of the playlist). I will run some tests against other vendors as well, and we can finalize things early next week. Cheers!

@andrlos
Copy link
Contributor Author

andrlos commented Feb 22, 2024

@smlambert don't bother trying other platforms than those three for now, they will all get stuck on the following block of code https://github.com/andrlos/TestHeadlessComponents/blob/main/testHeadlessComponents.sh#L21 :-)

@smlambert
Copy link
Contributor

re: #5084 (comment) - got it, thanks!

@andrlos
Copy link
Contributor Author

andrlos commented Feb 26, 2024

https://ci.adoptium.net/job/Grinder/8952 windows seems to be solved, now lets see about mac..

@andrlos
Copy link
Contributor Author

andrlos commented Feb 26, 2024

okay I got it to work on both mac and windows https://ci.adoptium.net/job/Grinder/8961/ <- hopefully a correct grinder run link :D
anyway I will need some time and maybe some more background about how to implement that groovy code for my scenario with DISPLAY to fill in the XDISPLAY variable.. the code itself seems reasonable and exactly what I need, there will just need to be a few more iterations about utilizing it.
To the USE_JRE variable.. we can discuss and brainstorm it more.. the test was originally designed for jre environments and as such it has its own portable that it is downloading (currently one of adoptiums I believe) that it uses for compilation.. but it can utilize any jdk we throw at it by merely filling a variable.

@karianna karianna requested a review from smlambert February 27, 2024 04:09
@smlambert
Copy link
Contributor

Grinder against an openj9 distribution: https://ci.adoptium.net/job/Grinder/8984

Comment on lines 60 to 70
<target name="installBrewBash">
<exec executable="ruby" failonerror="true">
<arg value="-e" />
<arg value="'$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)'" />
</exec>

<exec executable="brew" failonerror="true">
<arg value="install" />
<arg value="bash" />
</exec>
</target>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, we don't install prerequisites as part of test execution. Test prereqs are added and managed via ansible playbooks in the infrastructure repo and documented in the Prerequisites doc. For test execution, we want to leave the machines in the same state we found them (cleaning up temp files, not installing new tools), so if we were to consider changing our practices and install something, we would then likely plan to uninstall at the end of a run.

Even though most of our mac nodes are Orka dynamic agents, other vendors may use static / real hardware.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh sorry.. I did not realize this. Our VMs are always thrashed after the run, so this did not occur to me...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try to get rid of the associative array altogether.. it will take me a day or so but will be worth it since it is the only reason to have this dependency

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the record, @sxa thought this prereq was already in our ansible playbooks, but I have not checked, and clearly if you were failing in Grinders, not deployed out to all nodes (or possibly to Orka nodes), but ya, good to try to minimize prereqs where possible

@andrlos
Copy link
Contributor Author

andrlos commented Feb 28, 2024

okay.. this is embarassing.. it turns out that the
declare -A
is not such a problem on Mac afterall..
I don't have a clue how come it works now but it just does even on Mac..
All it took was to explicitly run the script with bash..
I tested even on GH actions and even there there is no more a need for a homebrew install (and I am very much sure there was such a need a few months back)
grinder run:
https://ci.adoptium.net/job/Grinder/9013/

@smlambert
Copy link
Contributor

declare -A
is not such a problem on Mac afterall..

Sweet!

@smlambert
Copy link
Contributor

A few more Grinders for good measure:
https://ci.adoptium.net/job/Grinder/9022

Copy link
Contributor

@smlambert smlambert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @andrlos !

@smlambert smlambert merged commit 00ea82a into adoptium:master Feb 28, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants