Build chain order with composite configurations
I have the following build chain (using snapshot dependencies) setup in TemaCity 2017.2
A -> B -> C
Meaning that configuration C depends on configuration B, which depends on configuration A.
The snapshot dependencies are set to "Alwasy run a new build".
The C configuration is the overall product which is used to verify that the entire product can be built.
The C configuration is just a simple Maven build configuration, but configurations B and A are both composite configurations with dependencies to a number of other plain Maven configurations (like A1, A2 and B1, B2 etc).
In other words: configuration C depends on composite configuration B (with a number of Maven configurations), which depends on composite configuration A...
My problem is that I don't think TC runs the build chain in the right order.
If I trigger a run of configuration C, I would expect TC to resolve the build chain and do the following:
- First build composite configuration A with all it's composite dependencies (parallel is OK for the dependencies within the composite configuration)
- Then build composite configuration B with all it's composite dependencies (parallel is OK for the dependencies within the composite configuration)
- Finally build plain configuration C
Looking at the build chain running, I can see the order of execution, and I can see that composite configuration B runs before A.
My question is:
Can I used build chains (snapshot dependencies) and composite configurations like this and expect the described behaviour (ordering),
OR am I doing somtheing wrong / should I take another approach to this sort of testing.
OR am I doing somtheing wrong / should I take another approach to this sort of testing.
Thanks.
Michael
Please sign in to leave a comment.
If that's the order you have set up, B should never start before A is finished, but it might be possible for some other dependencies of B to be run before A. Snapshot configurations are explicitly meant to keep order, so if this is not the case in your situation, I think we are going to have to dig into the details. We would need to see the whole chain, details on what order is actually happening and what would you exactly expect.
If you can, please share the screenshots with that and your comments, if they have private information, please use the "Submit a request" button on top of this page.
Hi Denis
First of all, thank you for your reply.
This means that TC should do what I expect given the setup described. I will start by going through my setup again to see if I have missed a dependency, which could cause B to be started before A. I will also try to minimize the setup to have something more traceable, in case we need to dig deeper.
BR
Michael
Hi
I think I know why this does not Work (the way I had hoped). Consider the following simplified setup:
I have created the following snapshot dependencies:
"D_Product" depends on "C1_Contracts" (composite configuration) - depends on "B_Common Util" (and C1_Contract DH B2B) - depends on "A_Foundation".
Having made a change to the "A_Foundation" CVS repo and then running a build on "D_Product", TC shows:
So "D_Product" is now queued.
"C_Contracts" is running (a build chain and therefore C1_Contract DH B2B which is part of the composite configuration "C_Contracts")
"A_Foundation" is also running.
BUT "B_Common Util" is not running - only queued.
Looking closer at the composite configuration "C_Contracts":
This is the problem. You can have a any given configuration depend on a composite configuration (which will create the right build chain), but you cannot do the above.
What I really want is for configuration "C_1_Contract DH B2B" to depend on "B_Common Util" - in this simplified setup that's no problem - I could just add that snapshot dependency directly to "C_1_Contract DH B2B". However - the complete setup is much bigger with more contracts and other configurations with a lot of dependencies. In that setup, I would have to add the dependency to "B_Common Util" to EACH single contract...
This is really about grouping things.
I would like to be able to create some kind of group (with a number of configurations as members of the group) and be able to be to express that ALL configurations inside that group, have dependencies on other configurations. Meaning that if the group itself (any of its member configurations) is resolved as part of a build chain, then the group's dependencies must be built before the group (and any of its members).
Thanks.
Michael
I see now that there is a quite complex scenario here. For starters, snapshot dependencies, as we discussed, are thought to maintain order, so it follows that everything that should wait on A should depend on A. I'm afraid there is no way around waiting rather than adding such dependencies.
With this in mind, there are at least a couple possible suggestions, although you would need to explore the possibilities yourself and how to apply them to your scenario:
-Build templates. Build templates can be assigned to an arbitrary number of build configurations, and you can then assign the dependencies on the template directly. All the configurations inheriting from it will pick up the dependencies (but due to the build queue optimization only one would be run, they simply will all wait until it's finished to continue). Templates can share additional common configuration, but are not required to, you can have them only for the dependencies if you want.
-Versioned settings. Our Versioned Settings system, while initially thought for keeping track of the changes that happen throughout the configurations, also allows to accept changes that are performed on the VCS Root and apply them automatically to the build configurations. This means that you can create a script that performs automatically the changes on the XML files, or even use Kotlin to programatically generate the configurations. Some examples of this last one here: https://blog.jetbrains.com/teamcity/2017/01/kotlin-configuration-scripts-creating-configuration-scripts-dynamically/
We have a few build targets that take a long time to check for changes, they are part of build chains.
Is there a setting on the server that can speed the checking for changes? We have plenty of CPU to dedicate for that operation.
Hi Paul,
I'm not sure why you posted in this thread, as your question is completely unrelated. Please try to create a new topic if you'd like to follow up with this.
Regarding your issue, it's hard to say. It seems to only have taken 1 minute, probably spent the rest of time waiting in the queue. Taking 1 minute might be much or not depending on what it's doing in the meantime. We don't impose ourselves any limitation, so there is no internal property to "speed up the process". There might be configuration or properties that might have an impact on it but they would depend on what exactly is going on.