Coping with build order requirements in automated builds
- by Derecho
I have three Scala packages being built as separate sbt projects in separate repos with a dependency graph like this:
M---->D
^ ^
| |
+--+--+
^
|
S
S is a service. M is a set of message classes shared between S and another service. D is a DAL used by S and the other service, and some of its model appears in the shared messages.
If I make a breaking change to all three, and push them up to my Git repo, a build of S will be kicked off in Jenkins. The build will only be successful if, when S is pushed, M and D have already been pushed. Otherwise, Jenkins will find it doesn't have the right dependent package versions available. Even pushing them simultaneously wouldn't be enough -- the dependencies would have to be built and published before the dependent job was even started. Making the jobs dependent in Jenkins isn't enough, because that would just cause the previous version to be built, resulting in an artifact that doesn't have the needed version.
Is there a way to set things up so that I don't have to remember to push things in the right order?
The only way I can see it working is if there was a way that a build could go into a pending state if its dependencies weren't available yet.
I feel like there's a simple solution I'm missing. Surely people deal with this a lot?
