作业设置
作业包含依次运行的各个构建步骤。本文介绍用于控制执行顺序的常用设置。 本文介绍用于控制执行顺序的常用设置。
编辑作业设置
要查看和编辑作业设置，请点击右上角的 设置切换 ，然后点击任意作业图块（或点击“添加”图块以创建新作业）。
您还可以从可视化编辑器切换到代码，直接编辑标记。
步数
使用本节可以定义作业所执行的操作，例如构建与测试项目、运行自定义脚本、上传 Docker 镜像等。
目前，管道支持四种类型的可添加步骤。 这些都是对应 经典构建配置步骤的轻量版本。
脚本
这是一个通用步骤，可直接在代理机器终端中执行命令。 因此，您可以与安装在代理上的任何工具进行交互：cURL、Python、MSBuild、Homebrew 等。
例如，以下步骤会下载由目标构建配置生成的工件：
Gradle
此步骤专为与 Gradle 构建工具交互而构建，可以用于构建、测试和打包 Java、Kotlin、Groovy、Scala、Swift 等项目。
Maven
Maven 构建步骤旨在使用 Apache Maven处理 Java、Kotlin、Groovy 等项目。
构建功能
与步骤类似，构建功能执行特定操作。 不过，功能会在构建生命周期的预定点运行，而步骤更灵活，可以按需安排。
例如：
脚本 是一个执行终端命令的构建步骤。 其行为取决于您的设置：可以运行单条命令或完整脚本，使用内联或基于文件的脚本，并可以在流水线的任意点执行。
Swabra 是一个构建功能，在特定时间（构建前或构建后）执行一项特定操作——清理构建过程中产生的文件。
目前，流水线仅支持构建配置中部分可用的 构建功能：
- 构建文件清理器（Swabra）
跟踪在构建期间创建、修改或删除的文件。 新文件会在构建结束后或下次构建启动时被移除，而被修改或删除的文件则会在构建日志中报告。 您还可以将跟踪范围限定为特定文件和目录。
了解更多： 构建文件清理器 （Swabra）
- 构建缓存
通过复用之前运行中生成的文件，如已下载的 npm 软件包或 Maven 本地仓库工件 ，提升构建性能。
了解更多： 构建缓存
- 可用磁盘空间
自动清理代理磁盘，确保新构建有足够的可用空间。
了解更多： 释放磁盘空间功能
- XML 报告处理
允许 TeamCity 使用由外部工具生成的报告文件。 支持的格式包括测试框架报告，如 JUnit、Maven Surefire/Failsafe、TRX 和 Google Test，以及来自 SpotBugs、PMD、Checkstyle 等工具的代码分析报告。
了解更多： XML 报告处理
优化
本节介绍可显著加快 Pipeline 运行速度的设置，从而节省时间、资源，对于云代理还能节省基础架构成本。
并行测试 — 允许 Maven 和 Gradle 步骤将测试套件拆分为多个批次，在不同构建代理上并行启动 N 个虚拟构建。
重用作业结果 — 如果所有启用的 仓库中没有新更改，TeamCity 将跳过重新运行该作业，并重用先前运行中的工件、状态和结果。 这样可确保仅执行受最近更改影响的作业。
重用的作业将在 UI 中明确标记，以避免混淆。
请注意上方的“优化”图块：TeamCity 此次运行速度几乎比上次快 5 倍，重用运行节省了约 80% 的时间。
Agent Requirements（代理要求）
TeamCity 会自动跟踪代理软件，以确保仅将排队的运行分配给兼容的代理。 例如，如果 Maven 步骤必须在容器中运行，则不安装 Docker 或 Podman 的代理将被标记为不兼容。
同样，如果作业使用了未在项目、 流水线 或 作业参数 部分定义的参数，TeamCity 最后会在代理机器上查找该参数值。 例如，如果命令行步骤运行 echo %myParam% 时引用了未知参数，则仅参数 "myParam" 不为空的代理可以运行该作业。
代理要求 部分允许您为符合条件的代理定义附加条件，如名称、硬件规格或已安装的工具。
TeamCity 会显示适用于大多数基本代理硬件要求的预设选项：CPU 核心数、代理内存总量及 CPU 架构。
点击 添加自定义要求 以定义您自己的要求。 每个要求都是一个 <agent.parameter> <运算符> [值] 表达式。 TeamCity 会针对每个已授权代理计算这些表达式，并将返回 "true" 的代理标记为符合条件，其他代理标记为不兼容。
- 代理参数
代理计算机报告的一个参数，其值必须符合所需条件。 以下是一些常见代理参数示例：
teamcity.agent.jvm.os.arch— 报告代理计算机的架构。 例如，对于在 Apple ARM 设备上运行的 macOS 代理，结果为aarch64。env.ANDROID_SDK_HOME— 返回代理计算机上 Android SDK 的安装路径。 例如，/home/builduser/android-sdk-linux。teamcity.agent.jvm.user.timezone— 存储代理计算机的时区。 例如，Etc/UTC。MonoVersion— 返回 Mono 平台的版本信息。 例如，6.12.0.200。
导航至 代理 | <TeamCity_Agent> | 代理参数 选项卡，查看代理报告的参数，并查找存储硬件和软件数据的参数。
另见： 预定义构建参数列表。
- 运算符
用于将实际代理参数值与给定值进行比较的逻辑运算符。 例如，“小于”、“以...开头”、“包含”等。
另请参阅： 需求条件
- 价值
要与代理参数值进行比较的自定义值。 唯一不需要值的运算符是
exists，用于检查代理是否报告了所需的参数，无论其实际值为何。
以下 YAML 示例定义了三个要求：16 GB 的 RAM、至少 10 GB 的可用磁盘空间，以及已安装的 Python 3。 标准 TeamCity 要求使用较简洁的 别名：值 语法，自定义要求则使用完整的 <参数> <运算符> [值] 表达式（并带有用于公共标题的额外 名称 参数）。
参数
参数是名称－值对，用于将原始值替换为引用。 当 TeamCity 遇到参数引用（%\形参名称% ）时，会将其替换为实际的参数值。
TeamCity 支持两种参数层级：pipeline 参数和 job 参数。 流水线参数同时可作为输入参数和输出参数。
作业参数},{ 通常仅在其所属父作业中可用。 默认情况下，它们包含
env.前缀。 要从 下游 作业访问作业参数，请使用job.<source_job_ID>.<parameter_name>语法。 下方示例展示包含一个参数的作业。 下游作业通过引用该参数来指定自身的ParamJobB。jobs: Job1: name: Job 1 steps: - type: script script-content: |- echo "Print Job1 parameter: %env.ParamJobA%" # prints 'foo' parameters: env.ParamJobA: foo Job2: name: Job 2 dependencies: - Job1 parameters: env.ParamJobB: '%job.Job1.env.ParamJobA% bar' steps: - type: script script-content: |- echo "Print parameter from upstream Job: %job.Job1.env.ParamJobA%" # prints 'foo' echo "Print modified parameter: %env.ParamJobB%" # prints 'foo bar'管道输入参数 会在本流水线的所有作业间共享。 请参阅 流水线参数 了解详情。
管道输出参数 无法在同一流水线中使用。 而是传递给同链路下游的流水线和配置。 请参阅 管道依赖项 了解详情。
作业步骤还可以发送 setParameter 服务消息 ，以动态编辑参数值（或创建新参数）。 请注意，修改后的值仅在发送该消息的步骤结束后才可用。
输出文件
作业共享的文件可以作为工件、供下游作业使用的内部文件，或者两者兼而有之。
- 工件
工件是在运行结果页面的 工件 选项卡中显示的文件。 具有查看项目权限的用户可以将这些文件下载到本地存储。
您可以通过两种方式查看工件：
在运行结果页，打开 工件 选项卡，可查看流水线中各作业发布的所有工件。
在同一页面，选择某个作业以打开其侧边栏，然后切换至 工件 选项卡以查看该作业生成的工件。
- 共享文件
共享文件将沿 pipeline 向下传递到后续作业。 这些通常是内部文件或尚未完成的文件。
与工件不同，共享文件不会在构建结果页的主 工件 选项卡中显示。 不过，它们会显示在作业侧栏的 工件 选项卡中，打包为隐藏的 .shared_files.zip 压缩包。
下面的 YAML 示例展示了一个作业创建并修改文件，然后另一个作业导入该文件并打印其内容。 “作业 2” 接着将该文件发布为工件。
jobs: Job1: name: Create file steps: - type: script script-content: |- touch sample.txt echo "File created by Job 1, build #%tc.build.number%" >> sample.txt files-publication: - path: sample.txt share-with-jobs: true publish-artifact: false Job2: name: Print file contents dependencies: - Job1 steps: - type: script script-content: cat sample.txt files-publication: - path: sample.txt share-with-jobs: false publish-artifact: true
这两种类型并不互斥：添加输出文件时，您可以同时勾选 共享文件 和 工件 复选框。
请注意，共享文件会保留其父目录层次结构，而工件不会。 下例展示了一个作业生成两个文件，均位于各自的文件夹中。
尽管步进脚本和 files-publication 规则几乎相同，结果却略有不同。 共享文件会与其父文件夹一起打包进隐藏的 ".shared_files.zip" 压缩包，而工件则原样归类于 "publish" 目录下。
存储库
本节允许您选择该作业应签出哪些远程仓库。 要添加仓库，请在 仓库 部分中创建一个新条目，位于 pipeline settings 中。
默认情况下，源代码将签出至代理工作目录的一个子文件夹中。 为确保代理在运行其他作业时不会频繁丢失某个作业的源代码，该子文件夹的名称是自动生成的，并对每个作业唯一（例如， /mnt/agent/work/6fa95896c6cadf54）。
您可以通过 存储库 部分项的相应选项，指定用于签出源代码的自定义目录。 签出目录的路径可以是绝对路径，但强烈建议使用相对路径（MyCustomFolder ）或引入预定义 TeamCity 参数的路径（%teamcity.agent.work.dir%/MyCustomFolder）。
下图概述了构建过程中涉及的核心目录之间的关系。
请参阅以下文章以了解更多信息：
Agent Home Directory（代理主目录）—— 构建代理的安装目录。
Agent Work Directory（代理工作目录）—— 构建代理主目录中的子文件夹，用于存储构建相关文件。
Build Checkout Directory（构建检出目录）—— 构建代理工作目录中的子文件夹，用于存放所有签出的源代码。
Build Working Directory（构建工作目录）—— 构建步骤开始所使用的目录（默认等于“构建签出目录”）。
集成
pipeline 和作业设置面板都包含一个 集成 部分，用于连接私有 Docker 和 NPM 注册表。
在 pipeline 设置中，您可以管理作业可用集成的完整列表。
在作业设置中，开关允许您选择该作业应自动登录哪些注册表，从而确保构建步骤能够访问所需数据。
传统 TeamCity 构建配置通过“连接 + 构建功能”组合支持此功能：
Docker Registry 连接与 Docker 注册表连接 Docker 构建功能。
NPM Registry 连接与 相关构建功能 ，用于 Node.js 注册表。
如果某个项目中已有 Docker 或 NPM 连接，则该 pipeline 会在其“集成”部分下显示该连接。
这些继承的集成无法直接通过 pipelines 设置面板编辑，您需要在项目设置中修改其源连接。