根据我对TeamCity如何工作的观察，我注意到在执行完所有步骤后评估构建失败条件。这非常烦人，因为如果任何构建失败条件满足，我就无法执行该步骤。
我没有提到常见的构建失败条件，例如＆＃34;至少有一个测试失败＆＃34;。我指的是手动添加的故障情况，例如公制更改。
当我检查构建日志时，我清楚地看到所有步骤都已执行，并且最后它只评估构建失败条件，并记录相应的错误（如果有的话）。但是在这个过程中为时已晚，因为条件步骤（必须基于＆＃34失败;如果构建状态成功，则仅执行＃34;）已经执行。
问题：我怎样才能做到这一点？
从上面可以看出，我已经尝试了一个条件步骤并添加了构建失败条件，但无法达到预期的结果。
为了清晰起见而添加：
基本上，我有一个部署应用程序的步骤。但是，我的期望是，如果满足构建失败条件，我不应该部署。我所拥有的构建失败条件的示例是度量标准更改。显然，这可以表示为构建失败条件，并且我可以在构建状态不成功的情况下使构建步骤失败。然而，似乎并不是构建步骤的行为方式，所以我感到困惑（我认为这是构建步骤中条件的目的）。我错过了什么？
答案 0 :(得分：1)
构建和部署＆＃39;构建配置＆＃39;应该分开。
如果构建＆＃39;构建配置＆＃39;成功完成（不激活失败条件）然后这将触发部署＆＃39;构建配置＆＃39;跑。
答案 1 :(得分：1)
TeamCity的最新版本具有“执行步骤”选项和“仅当构建状态成功时”选项-该选项还应考虑服务器上的构建失败情况。
答案 2 :(得分：0)
这是因为在完成所有构建步骤时会检查构建失败条件。这是有道理的，因为对于像度量变化这样的条件你应该等待构建完成，我的意思是你不能考虑计算工件大小或在日志中寻找特定文本或类似的东西，直到构建完成。
这就是说 - 对于您的情况，您应该考虑编写在失败时使用非零退出代码退出的构建步骤，然后您可以在If all previous steps finished successfully Execute step中使用build step选项。