Extending test timeout on slow platforms

[adamfarley]

Some platforms can take over 10 hours to run a full suite of extended.openjdk tests, even when split between 3 parallel machines.

Therefore we should extend the timeout to allow the tests to run to completion.

[github-actions]

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 Guidelines

If you have not done so already, please familiarise yourself with our Contributing Guidelines and Code Of Conduct, even if you have contributed before.

Tests

Github 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 run tests on this PR.
If you are not an admin, please ask for one's attention in #infrastructure on Slack or ping one here.
To run full set of tests, use "run tests"; a subset of tests on specific jdk version, use "run tests quick 11,21"

[adamfarley]

Fixes #852

[sxa]

Anything further needed for this to have the WIP prefix removed?

[adamfarley]

Just a successful test run. Whether it prevents the issue or not, I want to be sure this hasn't broken anything.

[sxa]

Just a successful test run. Whether it prevents the issue or not, I want to be sure this hasn't broken anything.

While you're waiting - any chance you can adjust the commit message to call out s390x and riscv64 explicitly - it can be really useful when searching commit messages in the future.

[adamfarley]

Just a successful test run. Whether it prevents the issue or not, I want to be sure this hasn't broken anything.

While you're waiting - any chance you can adjust the commit message to call out s390x and riscv64 explicitly - it can be really useful when searching commit messages in the future.

Sure, done.

[karianna]

@adamfarley Is that a manual test run or since hte GH Action Checks have passed we can merge this?

[adamfarley]

@adamfarley Is that a manual test run or since hte GH Action Checks have passed we can merge this?

It's a manual test run referred to in the issue here.

Unfortunately the change does not appear to be working. I'm looking into it now.

[adamfarley]

Ok, here's a rerun with some debug messages:

https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk22/job/jdk22-linux-s390x-temurin/16/

And here's a rerun using the upstream pipeline job, in case this is one of those things that's outside the scope of the job parameters.

https://ci.adoptium.net/job/build-scripts/job/openjdk22-pipeline/118/

[adamfarley]

Ok, I've put in the fix for the TIME_LIMIT-not-being passed downstream issue, and I've refined the formatting.

If this job passes the variable correctly, we're good to merge.

https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk22/job/jdk22-linux-s390x-temurin/21/

[adamfarley]

Variable passes correctly. Good to go. Requesting a re-review as the code was changed significantly after the last reviews.

[sxa]

Noting that https://ci.adoptium.net/job/Test_openjdk22_hs_extended.openjdk_s390x_linux_testList_0/13/ took just over 20 hours on test-marist-ubuntu2204-s390x-1) (That job seems to have been run with TIME_LIMIT=30 - perhaps this needs to be a touch higher at 25? Or we need to understand why that machine seems slower than the others and resolve that :-) https://ci.adoptium.net/job/Test_openjdk22_hs_extended.openjdk_riscv64_linux_testList_0/4/ on RISC-V was similar (just over 20 hours) so while we have a wider range of machine specs on that platform 25 might be a preferable option there too.

[adamfarley]

Okie dokie, will make another PR. - #928