Throttle large parallel fan-out with throttle categoy#257
Conversation
gilles-peskine-arm
left a comment
gilles-peskine-arm
left a comment
There was a problem hiding this comment.
LGTM on code reading. But I'm not a Jenkins or Groovy experts.
Have you run a test build? I'd like to see a passing build, and a build where some jobs fail.
github-project-automation
Bot
moved this to In Development
in Roadmap pull requests (new board)
saheerb
force-pushed
the
main
branch
2 times, most recently
from
b0cfa65 to
04e6a79
Compare
saheerb
changed the title
I changed the approach after recommendation from cloudbees. Test run: |
gilles-peskine-arm
left a comment
gilles-peskine-arm
left a comment
There was a problem hiding this comment.
Not sure how it helps, but ok on code reading. Approved pending validation through a CI run.
Can you please run a test job on the normal CI instance (not the test instance, which might be configured differently), e.g. the PR job on https://github.com/Mbed-TLS/mbedtls-restricted/pull/906 ?
I dont think I can test this change in PROD without merging it in. At least not without editing job/pipeline lib config. What I suggest is to bring this in and if it doesn't work we can alway revert. |
Wrap the main tls-testing parallel fan-out in the mbetls-parallel-limit throttle category. This applies to both PR and release job paths and is intended to reduce queue pressure from very large numbers of EC2-backed node() branches entering the queue at once. This is a workaround to limit controller-side scheduling contention until the underlying CloudBees/Jenkins issue is better understood. Signed-off-by: Saheer Babu <saheer.babu@arm.com>
|
Currently the CI is working as expected and we have a fair amount of PR under test. I would not merge that change right now. |
3 participants
Wrap the main tls-testing parallel fan-out in the
mbetls-parallel-limit throttle category.
This was the recommended approach by cloudbees to reduce queue pressure.