Coping with build order requirements in automated builds
Posted
by
Derecho
on Programmers
See other posts from Programmers
or by Derecho
Published on 2014-08-08T09:00:03Z
Indexed on
2014/08/21
16:29 UTC
Read the original article
Hit count: 181
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?
© Programmers or respective owner