-
-
Notifications
You must be signed in to change notification settings - Fork 314
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
docker: switch to a bespoke test container #5683
base: master
Are you sure you want to change the base?
Conversation
Removing ADDITIONAL_LABEL values from Grinder run and filling in CLOUD_PROVIDER=azure, since that is how the tests are expected to be launched in general pipeline code: Run some additional grinders, varying test group and JDK version: sanity.system, JDK21:
special.functional, JDK11:
|
@ShelleyLambert looking at that job it didn't run in a docker container? I think it's because we need to add the |
Rebuilding https://ci.adoptium.net/view/Test_grinder/job/Grinder/11171/ (PARALLEL=Dynamic, NUM_MACHINES=5) |
Looking more closely, it looks like it found a static machine, but still ran on a dynamic machine (test-linux-x64-b97844), console output from https://ci.adoptium.net/view/Test_grinder/job/Grinder_testList_3/10/console
In 'real' pipeline runs, the test pipeline code will first try to send to idle static machines and spin up dynamic ones as needed after that. As per the current design, we will not be passing in ci.agent.dynamic explicitly when we trigger test pipelines (only updating to set CLOUD_PROVIDER=azure), so I wanted to check that it works as designed. |
Right okay, so if you don't expect the dynamic label to be used I'll have to tweak the existing code slightly, I'll have a playb |
@smlambert I've updated the code so it won't explicitly require someone to pass the dynamic label to the job anymore. As long as the cloud is set as Azure it will default to using a container image |
@gdams - you do not need to make the change on L461. I was explaining how the current logic already works, not asking for you to change your PR, which looks fine as it is, I am just running many additional tests to verify that each test group works on these agents (please see what we do on L351). |
reverted PTAL |
Couple extra Grinder runs to verify: |
https://ci.adoptium.net/view/Test_grinder/job/Grinder/11321/ fails with:
This failure is unrelated to this PR (related to: #5754) |
I will launch a couple of Grinders to 'exhaust' our list of static nodes, and see the use of dynamic agents shortly.
Most failures related to not finding files that are generated and expected to be found within the workspace, and wondering if that relates to the comment in the PR for some other changes "Needs to be inside the workspace as the docker container won't have permissions to write to higher level directories". Do we need to redefine some other env var for where TKG generates parallel make files ?
|
@gdams - can you let me know how you pushed the image this PR is using to ghrc.io? I think we want to create a workflow that will allow us to update it as new test dependencies are discovered (fakeroot, etc). |
Most failures mentioned in #5683 (comment) are due to the DYNAMIC_COMPILE=true, which only works for functional and external right now. With DYNAMIC_COMPILE=true, the compile step will be skipped https://github.com/adoptium/aqa-tests/blob/master/buildenv/jenkins/JenkinsfileBase#L710-L719. The two child builds without that issues https://ci.adoptium.net/job/Grinder_testList_0/358/ and https://ci.adoptium.net/job/Grinder_testList_2/54/ only run with targets ending with _0 ( Failed one including target ending with _1 or_2 , which I'm not sure why it works) I rerun the build https://ci.adoptium.net/view/Test_grinder/job/Grinder/11554 with DYNAMIC_COMPILE=false twice. DYNAMIC_COMPILE=true https://ci.adoptium.net/job/Grinder/11686/ https://ci.adoptium.net/job/Grinder/11685/, both has child jobs running on dynamic agents. All builds are running haven't hit any special issues with dynamic agents . Though the thing I don't understand is why only jdk_***_0 are generated. I see, there are message |
|
It seems with dockerimage as agent all build parameters include empty string will be considered as environment variable. So even the JVM_OPTIONS='' it still cause the variations are ignored. Issue opened adoptium/TKG#640 This may not only affect JVM_OPTIONS. Any conditions based on if a build parameter is a set environment variable may be affected. Need to double check if there are similar cases.
|
Also moved
LIB_DIR
andSYSTEM_LIB_DIR
to be inside the current workspace for docker builds due to permissions errorsCurrently using
ghcr.io/adoptium/test-containers:ubuntu2204
which is a lightweight image built loosely off the dockerStatic base images. PR incoming to the infra repo to regularly build this and we can add more base images where appropriate.Grinder to show this working: https://ci.adoptium.net/view/Test_grinder/job/Grinder/11160/