Can I create a build of builds that is not based on dependencies and triggers?
Is there a way to create a build configuration made up of other build configurations?
I have tried using a combination of dependencies and triggers but the lack of direct control over the order of things from my "parent build" is a big blocker.
I really just need a very simple build that specifies a list of builds to run in sequential order, thats it. Surely this is posible and I've missed something obvious?
Please sign in to leave a comment.
Hi Jeremy,
that should be doable by simply setting the chain as a set of dependencies, then setting the trigger in the last build of the chain. For example, if you have builds A, B, C and D, and they have to be run in that order, simply set D to depend on C, C on B, B on A, then set a trigger on D, and it will automatically pull up all the chain.
If B and C can be run at the same time, you can set D depends on B and C, B and C depend on A, again the trigger on D, and it will be performed in that order.
If you have a more complex scenario, please feel free to post an example and we'll try to suggest how to set it up.
@Denis Lapuente thanks for the reply, I have had to compromise in the end and do exactly what you have suggested. But my original scenario had an apposing direction of flow where by I needed triggers for down stream against the dependencies up stream. They were fighting each other. I have had to remove the down stream triggers on all of the dependencies to get things working. it does leave me with a build stream that will trigger upstream dependencies when I really dont need them to when run individually. But I am living with that for now.
My question was really just asking if it is possible to set up a very simple build of builds. Sometimes its just easier to do that without having to create notifications/events up and down stream. It feels a little bit like the development team decided to skip over the simplest implementation and start at a slightly more complex usecase, never mind.
Hi Jeremy,
I think that if you provided a more concrete example we would be able to help with structuring project, dependencies and triggers so that only what you need triggers when you need.
This said, in the last release we have included the "Composite Builds" feature: https://confluence.jetbrains.com/display/TCD10/Composite+Build+Configuration. This is literally a build of builds, but has several restrictions, so I'm not sure it would be ideal either.
Hi,
We are facing the same issue. We have four individual builds as they have own responsibility and can run individually. But when I consolidate all of them as Root / Parent (Composite build), all the four childs are started to run parallelly. There is no control over to run them sequentially. It really surprising me that TeamCity don’t have control on simple thing? I don't understand the benefits of composite build.
Here is our build configs
A - Preparing package - Configured VCS Repo A
B - Deploy the package (copy from A - set artifact dependency) in server - No VCS
C - Trigger Some Data Import Script - No VCS
D - Run Integration tests on that server - Scripts are from different VCS (Repo D)
P - Parent build (Composite build) which connects all above four builds
Note that, we don’t want to set SNAPSHOT dependency on each child build as it always run the all the dependencies before.
So how I can set them to run in particular order (Cannot run parallelly) in Parent build with snapshot or artifact dependencies or any other ways? Please suggest
Hi,
While I understand that you want to keep them separate without snapshot dependencies, the feature that you are requiring is exactly what snapshot dependencies are meant to do. There are two approaches to your scenario:
-Create your own script that runs in the "Parent" build (cannot be a composite build) that handles the triggering and paces it as you need.
-Extract a template of A, B, C and D, then create a copy of each build configuration based on the template (so that you can manage the configuration directly from the template), then set snapshot dependencies between the copies. That way you will have a build chain between the copies of A, B, C and D, and the separate instances to run them separately.
Hope this helps.
Hi,
Thank you for your reply.
I have few clarifications based on your answer. How does snapshot will help? Can you please share some sample configuration that would not force to rebuild with different VCS configurations. I want optionally to rebuild depedencies rather than depending VCS and other configs. Composite build will suit exactly for my case except the order of builds
#1) What kind of script I can use? any samples if you have, share.
#2) This option looks not possibile as we have to create two copies of all jobs and connect one set with snapshot dependencies. But this would not resolve our problem as we are running intergration job which has history of execution and test results, statistics, data. The reporting tool (allure) is required to take measures, statistics, other data from history. So we can't run two different jobs as we can't merge the history of both jobs.
Sorry, what I meant was that snapshot dependencies are the feature that enable build ordering. If you want build ordering, snapshot dependencies and finish build trigger are the only embedded options.
I don't have any example of such a script, but builds can be triggered manually via the REST API, which means that you could:
-Set up a build with the VCS Root that will produce the trigger
-That build just has a script, and it runs your own logic to decide which builds to trigger and in which order.
Other than that, without a decent understanding of your exact build process, it's hard to make any other kind of recommendation. I'm not familiar with allure so I don't know why it wouldn't be able to collect information from multiple builds, but if you want to run a multiple set of builds in order automatically, and other times manually in an arbitrary fashion, the only way using teamcity features is to use either snapshot dependencies or a finish build trigger (which have roughly the same effect)