配置构建步骤
一旦您拥有一个包含构建配置的 TeamCity 项目，您就可以配置 构建步骤。 一种构建配置可以包含多个步骤，这些步骤会依次执行。
构建步骤在 构建步骤 部分的 构建配置设置 页面中配置。 这个页面允许您：
手动添加新的步骤。
自动检测步骤通过扫描源 VCS 仓库来实现。
复制和删除步骤。
临时启用/禁用步骤。
每个构建步骤都提供与特定构建或测试工具的集成。 例如，在编译 VS 解决方案之前调用 NAnt 脚本。 您可以根据需要向您的构建配置中添加尽可能多的构建步骤。
本视频教程解释了如何根据项目需求选择构建步骤：
构建步骤会按顺序调用。
是否运行下一个构建步骤可能取决于前面构建步骤的退出状态，当前构建状态，或者 执行条件。
如果（1）构建过程返回的退出代码非零，并且（2）" 如果构建过程的退出代码不为零，则构建失败" 构建失败条件已启用（参见 构建失败条件 ），则认为构建步骤 失败 ；否则，构建步骤被认为 成功。
请注意，构建步骤的状态和构建本身的状态可能会有所不同。 所有构建步骤都可能成功，但是由于另一个构建失败条件，构建可能会失败，这并不是基于退出代码（如，测试失败）。 另一方面，如果构建步骤失败了，那么构建也会失败。
关于配置单个构建步骤的详细信息，请参考本节内的相关页面。
您可以通过 执行步骤 选项指定步骤执行策略：
仅当构建状态为成功时 — 在开始步骤之前，构建代理会从服务器请求构建状态，如果状态为“失败”，则跳过该步骤。 这考虑了服务器处理的故障条件，如测试失败或度量改变时的故障。 请注意，由于部分错误条件是在服务器上异步处理的（TW-17015 ），所以情况可能并不准确。
仅当构建状态为失败时 — 与上述相同，但如果构建状态为“成功”，代理会跳过该步骤。 此条件允许您只在构建失败时添加执行步骤。 例如，您可以运行任务，以撤销对引入了问题的远程存储库所做的最新更改。
如果所有先前步骤均成功完成 — 构建仅分析构建代理上的构建步骤状态，不向服务器发送请求检查构建状态，并仅考虑重要的步骤失败。
即使某些先前步骤失败 — 选择此项以使 TeamCity 无论前面步骤的状态和构建状态如何都执行此步骤。
Always, even if build stop command was issued — 选择此项以确保此步骤始终执行，即使构建被用户取消。 例如，如果您配置了两个步骤的此选项，在第一步执行过程中停止构建会中断此步骤，而第二个步骤仍将运行。 第二次发出停止命令将导致执行策略被忽略：构建将会被终止。
tip
提示:
您可以从原始构建配置设置页面将构建步骤复制从一个构建配置到另一个。
您可以根据需要调整构建步骤的顺序。 请注意，如果您有一个从模板继承的构建配置，您无法重新排序继承的构建步骤。 然而，您可以在任何位置以任何顺序插入自定义构建步骤（不继承），甚至可以在继承的构建步骤之前或者之间插入。 只能在原始模板中重新排序继承的构建步骤。
您可以暂时或永久禁用构建步骤，即使它是从构建配置模板继承的，也可以使用 构建步骤 列表最后一列中的相应选项。
自 TeamCity 2020.1 起，您还可以为构建步骤添加精细的 执行条件。
在构建触发后，构建代理检出源文件之前，会执行一个 引导步骤。 这允许您添加一个运行器（通常是 命令行 运行器），该运行器执行初始设置并确保后续步骤按预期运行。
要启用 bootstrap steps，首先将 teamcity.internal.bootstrap.steps.enabled=true 条目添加到 TeamCity 内部属性 或单个项目（作为该项目的 配置参数）。 此设置使您能够执行以下操作：
在步骤设置中启用 在引导期间运行 选项。
在配置的 构建步骤 页面上，单击 重排构建步骤 ，然后将所需步骤拖动到“准备阶段”块之前。
您可以创建一个带有 bootstrap 步骤的构建配置，并将此配置变成一个 template。 这种模板允许您在实际构建过程开始之前快速创建更多执行所需前提操作的配置。
Recipes 被视为单个步骤，因此无法分为在签出之前和之后执行的部分。
要在 Kotlin DSL 中将普通步骤变为 bootstrap 步骤，请添加 teamcity.step.phase 参数并将其值设置为“bootstrap”。
object MyConfig : BuildType({
// ...
steps {
script {
name = "Disk prep"
id = "simpleRunner"
scriptContent = "echo 'Initial setup'"
param("teamcity.step.phase", "bootstrap") // Bootstrap step
}
// Regular steps
}
// ...
})无代理构建步骤 是可以在外部软件中运行且无需附加 build agent 的步骤。
通常，一个正在运行的构建会占用一个构建代理，直到完全结束，即使其最后的步骤是在 TeamCity 之外执行的。 然而，如果构建不需要其代理进行一些剩余步骤，它可以从此代理分离。 代理一旦可用，即可立即分配给另一个构建。
这种方法可以节省代理的工作时间，并且对于使用第三方工具完成构建的配置来说是最优的：例如，运行众多测试或部署项目。 这样的构建可以在 TeamCity 外部完成；TeamCity 服务器将直接检测其状态报告，无需通过代理作为中介。
让我们考虑一个包含三个步骤的示例构建：编译，测试和部署。 即使部署步骤实际上是由外部软件执行的，所有这些都由代理处理。 代理仅在轮询外部软件并将构建状态报告给 TeamCity 服务器。
在无代理的方法中，代理无需处理最终的部署步骤，并且可以运行队列中的其他构建。 TeamCity 服务器将直接从外部工具中捕获以下报告。
另请参阅： 将构建与 Agent 分离
TeamCity 能够扫描项目的源 VCS 仓库，并在 Node.js、Kotlin、Python、Ant、NAnt、Gradle、Maven、MSBuild、Visual Studio 解决方案文件、PowerShell、Xcode 项目文件、Rake 以及 IntelliJ IDEA 项目中自动检测构建步骤。
在 构建步骤 中，单击 自动检测构建步骤 ，然后选择您希望添加到当前构建配置中的建议步骤。 您可以在之后更改它们的设置。
当扫描存储库时，TeamCity 会逐步在源树的两个最高级别中搜索项目文件。 在搜索时，它会考虑文件的扩展名。 例如：
PowerShell：
.ps1.NET：
project.json，.proj，.csproj，.vbproj，.sln
如果检测到的步骤已经手动添加到此配置中，TeamCity 将跳过这些步骤。
TeamCity 提供了报告给定 ID 步骤状态的 teamcity.build.step.status.<步骤_ID> 参数。 步骤 ID 显示在其名称下方，只有在创建它们时才可以编辑。
teamcity.build.step.status.<步骤_ID> 参数的可用值为：
成功— 当一个步骤没有错误地完成时。失败— 当一个步骤失败时。 即使所有构建问题都被 静音 ，也会报告此状态。已取消— 当该步骤运行时，构建被取消。
参数 teamcity.build.step.status.<步骤_ID> 只有在其对应的步骤完成后才会出现，而不是在构建开始的瞬间就可用。 这意味着既正在运行的步骤，也被跳过的步骤都无法获得其 teamcity.build.step.status.<步骤_ID> 参数。
您可以在构建结果页面的 参数选项卡 中检查所有步骤的状态...
...或通过 TeamCity REST API。
GEThttp://<SERVER_URL>/app/rest/builds/<BUILD_ID>/resulting-properties
您可以使用这些参数来创建自定义 构建步骤执行条件。
感谢您的反馈！