Set system test threads default based on CPU count

[thomashampson]

Description of work

In Jenkins, we set the value of BUILD_THREADS_SYSTEM_TESTS per machine to define how many system test to run in parallel. This adds logic to set a sensible default value of 3/16 multiplied by the core count.

To test:

This is running on a github self-hosted runner here:
thomashampson#3
And here is the run with this change in it:
https://github.com/thomashampson/mantid_github_actions_test/actions/runs/21756642425/job/62768649276?pr=3
The runner has 32 cores, check that the number of system test threads is 6. This currently what we set it to for our Jenkins agents for 32-core machines.

---

Reviewer

Your comments will be used as part of the gatekeeper process. Comment clearly on what you have checked and tested during your review. Provide an audit trail for any changes requested.

As per the review guidelines:

• Is the code of an acceptable quality? (Code standards/GUI standards)
• Has a thorough functional test been performed? Do the changes handle unexpected input/situations?
• Are appropriately scoped unit and/or system tests provided?
• Do the release notes conform to the guidelines and describe the changes appropriately?
• Has the relevant (user and developer) documentation been added/updated?
• If the PR author isn’t in the mantid-developers or mantid-contributors teams, add a review comment rerun ci to authorize/rerun the CI

Gatekeeper

As per the gatekeeping guidelines:

• Has a thorough first line review been conducted, including functional testing?
• At a high-level, is the code quality sufficient?
• Are the base, milestone and labels correct?

[cailafinn]

Looks good, can see that it's working for the GH-Actions node. Just a question about the calculation.

[cailafinn]

Do you think we need to make sure this is an integer here? I'm just considering the STFC Cloud might change again and not have a nicely divisible number of cores.

[thomashampson]

This will do integer division, so will take the floor. However, thinking about it more, maybe we should use RAM to determine the system test threads. E.g. our Windows runners currently have 16GB RAM and 24 cores. With the above calculation, that would mean 4 system test threads, but we are currently limiting to 2. What do you think?

[cailafinn]

I think that's probably more sensible, since RAM is the bottleneck for the problem we're solving by restricting anyway.