在TeamCity中多次并行构建后触发后续构建一次 [英] Trigger subsequent build once after multiple parallel builds in TeamCity

查看:418
本文介绍了在TeamCity中多次并行构建后触发后续构建一次的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经收集了超过150个项目,重新配置和优化到多个TeamCity配置,使用多个构建代理,以尝试改进我们的构建服务器性能,目前以高度顺序的方式构建。



技术(Web,dotNet,VB6和COM +)和系统架构的组合意味着有各种步骤(配置),现在可以并行运行,但需要



这是一个非常简化的依赖场景,但代表我们有一个问题....

  A  - > B  - >整理( - >部署)
A - > C - >整理( - >部署)

问题是,如果对A进行更改,将导致B和C触发,这将导致Collat​​e(和Deploy)步骤运行两次,尽管是A中的常见触发器。正如我所说,这是几乎二十个配置的真实集合的简化和频繁重建正在影响速度的提高。



任何人都可以建议任何方式,我可以确定的事实,B和C将被触发作为A的结果,并使分类步骤等待B和C完成,然后触发分页步骤?显然,对B或C的更改应该能够独立触发Collat​​e。

解决方案

我是TeamCity的新手,相信这是你需要的:




  • A :没有触发器或依赖性

  • B C :没有触发器,快照依赖于 A $ $ / code>和 C



单次推送将导致:




  • 正好一个构建 A B C 整理

  • <在 B C 之前创建
  • A >
  • B 和 C $ c>


  • 如果您想通过



    如果不同的构建使用不同的VCS存储库,那么您仍然不应该在<$上设置VCS触发器c $ c> A B C 而是在 Collat​​e 的VCS触发器上设置快照依赖项更改的触发器选项。


    We have over 150 projects which I have gathered together, reconfigured and optimised into multiple TeamCity configurations, with multiple build agents, to try to improve our build server performance which currently builds in a highly sequential manner.

    The mix of technologies (Web, dotNet, VB6 and COM+) and system architecture means that there are various steps (configurations) which can now run in parallel but which need to come together further down the track.

    This is a very simplified dependency scenario but representative of a problem we have....

    A -> B -> Collate (-> Deploy)
    A -> C -> Collate (-> Deploy)
    

    The issue is that, if a change is made to A, it will result in B and C both triggering which will result in the Collate (and Deploy) steps running twice, despite being a common trigger in A. As I say, this is a simplification of the real set of almost twenty configurations and the frequent rebuilds are impacting the speed improvements.

    Can anyone suggest any way that I can identify the fact that both B and C will be triggered as a result of A and make the Collate step wait for both B and C to complete before triggering the Collate step? Obviously a change to B or C should be able to trigger the Collate independently.

    解决方案

    I'm new to TeamCity, but I believe that this is what you need:

    • A: no triggers or dependencies
    • B and C: no triggers, snapshot dependecies on A
    • Collate: VCS trigger, snapshot dependency on B and C

    With that setup, a VCS single push will result in:

    • exactly one build of A, B, C and Collate
    • A built before B and C
    • B and C built before Collate
    • all built from the same point in VCS

    If you want to pass artifacts down the chain then you will need to define artifact dependencies as well.

    If the different builds use different VCS repositories, then you still should not set VCS triggers on A, B and C; instead you set the "Trigger on changes in snapshot dependencies" option on the VCS trigger for Collate.

    这篇关于在TeamCity中多次并行构建后触发后续构建一次的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆