I am working on tests of embedded devices.
We have a device farm where several types of devices (say A, B and C), with many instances each (A1..A10, B1..B10, C1..C10), are available for remote testing. Each device is connected to a Jenkins node (with label 'A', 'B' or 'C'). So far, if we wanted to test systems of devices (A, B and C working together), they were connected to many Jenkins nodes ("multi-node setup") which had to be addressed individually.
Now we would like to replace these with single-node setups (all embedded devices A, B, C controlled by the same node). The current job structure involved reserving all nodes from a given multi-node setup on a high level and then calling different jobs one by one which then run on the respective node.
For reasons of maintainability and clear responsibility, I would like to retain the structure of several sub-jobs for given test.
My problem is now that the top-level job chooses any of the single-node setups, but of course all downstream sub-jobs need to run on that exact instance, which I can assure by passing the NODE_NAME of the top-level job as parameter. Unfortunately, since I should never have two (top-level) jobs running on a same instance in parallel, I can only define one executor per node. Which, in turn, means that a downstream job supposed to run on the same node as the top-level job will always wait for the executor to become available infinitely.
TL;DR: Is there a way to allow a downstream job to "reuse" an executor from an upstream job?
I am perfectly ok with "No, there isn't", but it would make managing our tests easier if there were. Otherwise I'll just have to roll all jobs into one big one.