Description

Use case:

Only a single instance of the iOS Simulator can be used at a time, therefore limiting its use to one project. Projects using the iOS Simulator should be the member of a shared category, which defines a maximum of one concurrent execution per node, since each node has only one iOS Simulator available at a time. Starting a second concurrent use of the iOS Simulator with xcodebuild tests will cause the first use to crash and fail.

Problem:

Assume X projects are in a category. When these projects have builds running that consume all of the available max defined concurrent executions, the plugin will correctly throttle new builds by placing them in the queue.

If more than two builds are queued and one build completes, all builds will start when only one should start (so long as the node/s have additional executors available).

Steps to reproduce:

1. Create a new throttling category "test-category" with a max of 1 concurrent build per node
2. Configure a single node N (master is okay) with 4 executors
3. Create four identical freestyle jobs A, B, C, and D configured to be a member of the throttling category "test-category", restricted to node N, and with one execute shell step "sleep 60"
4. Start each of the jobs in order - A, B, C, D

Expected:
1. Build for project A starts on node N
2. Builds for projects B, C, and D are queued
3. Build for project A completes
4. Build for project B (or another, however the queue is sorted) starts on node N
5. Builds for other projects remain queued
6. As the builds complete, pop one off the queue to consume the new slot

Oleg Nenashev
added a comment - 2015-04-28 16:27 jenkins-1.608 most probably fails due to JENKINS-27708
Could you re-test the case on 1.611 just to make sure?
There're many requests related to label-based restrictions. What does block you from using a global 1-per-node category?

Definitely duped the other issue. It wasn't necessarily related to label-based restrictions.

When I initially started looking into the issue it wasn't clear that core was responsible for handling a blocking mechanism such as this. Referring to the API documents and briefly looking through the code didn't make it too apparent.

Matthew DeTullio
added a comment - 2015-04-28 17:53 Definitely duped the other issue. It wasn't necessarily related to label-based restrictions.
When I initially started looking into the issue it wasn't clear that core was responsible for handling a blocking mechanism such as this. Referring to the API documents and briefly looking through the code didn't make it too apparent.