Two mutually exclusive groups of builds, each group can run in parallel

Hi,

I've got the following configuration:

a) Build & Deploy App A to Dev environment
b) Build & Deploy App B to Dev environment
c) Build & Deploy App C to Dev environment

d) Run test suite D on Dev environment
e) Run test suite E on Dev environment

The test suites D and E require all of A, B and C to be available (i.e. not redeployed halfway through) for the tests to pass, but both test suites can run at the same time.

Therefore when the tests D and E are running, I don't want A, B and C to be able to run.
Similarly when either A, B or C are running I don't want the test suites D and E to run.

A global state G could achieve this:
1. When any of A, B or C are running the global state G is "deploying"
2. D and E block while G is "deploying"
3. When the last of A, B and C finish the global state is a null value and D and E are unblocked
4. When any of D and E are running the global state is "testing"
5. A, B and C all block while G is "testing"
6. When the last of D and E have finished the global state reverts to a null value and A, B and C are unblocked

At the moment I can't see how to achieve this using shared resources. We have a partial solution with a shared resource called "dev" which A, B and C have read locks on and D and E have write locks on.
This means A, B and C run in parallel and do not run when D or E are running, but it also means that D and E run sequentially instead of concurrently.

Is there a way?

Thanks!

2 comments
Comment actions Permalink

Hi Oliver,

I think that the only option for now is to create as many resources as many build configurations you have. For example resources will be rb1, rb2, rb3, rt1, rt2, then

  • A write rb1 and read rt1, rt2
  • B write rb2 and read rt1, rt2
  • C write rb3 and read rt1, rt2
  • D write rt1 and read rb1, rb2, rb3
  • E write rt2 and read rb1, rb2, rb3
Not really good solution. We have a bit related feature request - please watch/vote for it. Also feel free to create new request in our tracker.
0
Comment actions Permalink

Hi Alina,

Thanks - the proposed solution in the issue you linked to sounds like it would give us the functionality we would like - upvoted.

Oliver

0

Please sign in to leave a comment.