问题标签 [build-chain]

All documentation on build chains on the TeamCity and also their blog postings deals with simples setup that don't expose the more complex setups that you may encounter in real life which brings me to the following question.

I have the need for a few more complex setups: A--\ /--D--\ C F B--/ \--E--/ Ideally A & B and D & E would run concurrently on different build nodes. A--\C/--E B--/D\--F In the above A & B run concurrent, as do C & D but C & D are only triggered if both A & B pass, the same goes for E & F they run concurrent, but only if both C & D pass. /-- B --\ A D \-- C --/ Ideally B & C should run in parallel on different nodes.

However TeamCity refuses to do this and all builds are un sequentially on a single build node which is highly annoying because it blows build times out of the water.

I've tried various combinations of Snapshot dependencies and Finish build trigger to no avail, TeamCity refuses to run any steps parallel.

I have a chained 2 builds scenario setup in VSTS.

I have a CI build, called 'Sync VSTS to GitHub' which runs two steps:

1. A powershell command which pushes the changes from that commit to GitHub.

2. Trigger another build, which compiles the solution, runs tests, deployments etc. (lets call it 'Proper Build')

This Sync VSTS to GitHub build has a trigger which detects when a push was made. That executes all OK.

The second build, the 'Proper Build' has no CI triggers defined. It is only supposed to be triggered manually (or rather by the 'Sync VSTS to GitHub' build).

What happens is that every time a push is made in Visual Studio, the 'Sync VSTS to GitHub' build is called. That succeeds, and then calls the Proper Build. And for some reason, this build is queued twice for the same changeset!
This second build is added after the first one runs for a short while:

Suddenly a wild build appears:

The only difference that I see between the builds is the user on behalf of which the build is triggered:

First Build:

Second Build:

What is particularly weird is that this does not happen when the build is queued manually from VSTS (without a new changeset). In such scenario, each build is triggered once.

The build task that triggers the Proper Build is this one: https://marketplace.visualstudio.com/items?itemName=benjhuser.tfs-extensions-build-tasks

This is how I configure it (I tried setting the highlighted option to different value, no effect).

To confirm - when this task is disabled, then the 'Proper Build' is not triggered at all (as expected)

Any idea how to avoid this duplication?

我正在运行 TeamCity 2018.1。我似乎无法在任何地方找到这种情况的答案。我发现了类似的问题，但它们并没有完全解决我想要实现的目标：这里和这里

我想要 TeamCity 中的以下流程

2.x 将不同的服务部署到测试环境，3 对测试环境运行冒烟测试，因此我们不需要运行多个。如果 1 被触发，这正是使用 Finish Build Triggers 时发生的情况。它最终使我们的提要变得混乱，并且我们最终在运行中间部署了服务的测试运行，这是我们绝对需要避免的。

要求如下：

• 我希望在 2.x 完成的任何时候触发 3，但我不希望运行 3 的多个构建，就像首先触发 1 的情况一样。
• 我还希望在其默认分支上有签入时触发 3。
• 3 上的触发器不应该在构建链的早期构建任何东西。这是一个昂贵的操作，并且会混淆我们在冒烟测试中的结果（失败是因为测试改变了吗？还是因为我们部署了更新的代码？）

我被引导相信快照依赖可以解决这个问题，但它并没有按照我想要的方式工作。当任何 2.x 成功完成时，它似乎都不会触发 3。此外，我绝对不希望在 3 由 VCS 更改触发时触发 1 或 2.x，无论“使用合适的构建选项”如何，这似乎都会发生很多。

此外，1、2.x 和 3 都从不同的存储库运行，因此它们没有共同的 VCS 根。所有 2.x 版本也是不同的存储库。我们也没有文物可以传递。

我怎样才能实现这个工作流程？

编辑：这可以通过在我的测试运行之前添加一个虚拟构建配置来实现吗？

我在团队城市中有 2 种不同的构建配置。每个都有自己的构建链。

第一个只是构建产品。第二个也构建产品，但也构建和运行单元测试。我们根据需要手动调用它们。

现在的问题是可以有一个入口点，通过一些参数/参数执行条件执行。（我点击按钮，提供简单构建或单元测试构建的选项）

我正在考虑使用“包装器”外壳脚本配置，它将根据给定的参数通过 REST 执行所需的链。然而，这有破坏完整性的明显缺点（你不能真正了解正在发生的事情）

欢迎任何其他解决方案！

有一个 TeamCity 构建链由多个构建组成，因此其中一些构建需要并行运行：

• 构建 1 运行
• 然后构建 2.1 和 2.2 并行运行
• 然后构建 3 次运行
• 然后构建 4.1 和 4.2 运行

这很容易设置。碰巧 2.1 使用与 4.1 相同的配置参数，而 2.2 使用与 4.2 相同的参数，因此最好以某种方式指定这些参数，这样如果 2.1 参数发生更改，那么 4.1 参数也会一致更改。

除了在构建级别之外，我没有看到可以设置配置参数的地方。它们可以设置在其他地方并在构建链的多个构建中重复使用吗？