The latest iteration uses this pattern:

@hashar It works, thank you. As for SonarQube Bot project, I look at the tag once in a while in case there is something that needs immediate attention, but it's not actively monitored. New requests are directed to the Test-Platform Team.

When the max instances value is increased beyond one for TwoColConflict, the tests become flaky, and we start seeing numerous errors. I also tested CampaignEvents, and the results were the same, tests pass with one max instance but fail with more than one.
We should investigate why Core Selenium tests remain stable when running multiple instances while extension tests fail under the same conditions. This may be due to a configuration difference, test structure difference, or even how the tests are written. If we resolve this, I believe we can significantly improve the robustness of the tests, which would allow us to enable multiple instances across all repositories and reduce wait times. The script generated report is a bit lengthy, but here are the TwoColConflict selenium test results for an example, no failures on 1 instance, but lots of failures on >1 instances:

For extensions, I tested out TwoColConflict, which is one of the repos that seem to have the most flaky tests. When running a max instance of 1, TwoColConflict Selenium tests seem to be stable with few to no errors, regardless of resources available. Example test run:

I created a script that automatically runs tests under different RAM and CPU configurations using Quickstart, with the ability to test various max instances. The script is not perfect, but from initial runs, I have noticed a few details.

TwoColConflict seems to be the most flaky extension according to this data. Running tests using the above config legend will help us see if we can get the tests to fail with the same common failures.

Using this config legend to test Core results on a local machine: