提交状态发布器
Commit Status Publisher 是一个 构建功能 ，允许 TeamCity 自动将您的提交的构建状态发送到外部系统。 该功能已作为一个与 TeamCity 一同捆绑的 开源插件 实现。
支持的系统：
GitHub （也支持拉取请求的构建状态）
Azure DevOps （支持的状态：Pending、Succeeded、Failed、Error）
Gerrit Code Review 工具 2.6+
Perforce Helix Swarm
从 2022.04 版本开始，Commit Status Publisher 会在构建被添加到队列时立即更新版本控制系统中的提交状态，为您提供最新的信息。 GitHub，GitLab，Space，Bitbucket Server 和 Bitbucket Cloud，Perforce Helix Swarm，以及 Azure DevOps 都得到了支持。
特定供应商的配置
GitHub
提交状态发布器支持以下格式的 GitHub URL：
对于 GitHub.com ：
https://api.github.com对于 GitHub Enterprise ：
http[s]://<主机>[:<端口>]/api/v3
为了进行连接，请选择一个可用的认证类型：
访问令牌 — 使用个人访问令牌或通过 OAuth 连接获取令牌。 令牌必须具有以下范围：
对于公开仓库：
public_repo和repo:status对于私有仓库：
仓库
如果您有一个已配置的 OAuth 连接 到 GitHub，您可以点击魔术棒按钮让 TeamCity 自动获取相应的访问令牌。
GitHub 应用程序访问令牌 — 如果此项目或任何父项目具有有效的 GitHub App 连接 ，Commit Status Publisher 可以使用可刷新访问令牌。 可刷新访问令牌是由 TeamCity 通过现有的 OAuth 连接从所需的 VCS 提供程序获取的短期令牌（与用户在 VCS 托管端手动生成的静态 PAT 令牌不同）。 有关生成和使用可刷新令牌的更多信息，请参阅以下文章： 管理可刷新访问令牌。
使用 VCS 根凭据 — TeamCity 将尝试从 VCS 根设置中提取凭据。 这个选项是为使用令牌（无论是静态/个人还是可刷新/OAuth）通过身份验证并使用HTTP(S)获取URL来获取仓库的VCS根设计的。 如果相关的 VCS 根使用匿名或标准的用户名-密码认证，或者使用 SSH 获取 URL，请选择其他选项。
密码 — 提供 GitHub 用户名和密码。 请注意，如果连接到 GitHub Enterprise 存储库，或者用户的 GitHub 帐户受到两步验证保护，密码认证将无法工作。 在这些情况下，您应该使用访问令牌代替。
GitLab
身份验证类型 选项允许您选择构建功能应使用哪种身份验证方法来访问 GitLab 存储库。
个人访问令牌 或 PAT 是静态身份验证令牌，您可以在 您的 GitLab 个人资料页面中生成。
可刷新访问令牌是由 TeamCity 通过现有的 OAuth 连接从所需的 VCS 提供商获取的短期令牌（与用户在 VCS 托管端手动颁发的静态 PAT 令牌不同）。 有关生成和使用可刷新令牌的更多信息，请参阅以下文章： 管理可刷新访问令牌。
使用 VCS 根证书 — TeamCity 将尝试从 VCS 根设置中提取凭据。 这个选项是为使用令牌（无论是静态/个人还是可刷新/OAuth）通过身份验证并使用HTTP(S)获取URL来获取仓库的VCS根设计的。 如果相关的 VCS 根使用匿名或标准的用户名-密码认证，或者使用 SSH 获取 URL，请选择其他选项。
GitLab API URL 字段接受 http[s]://<主机名>[:<端口>]/api/v4 格式的 URL。 此字段为可选项：如果留空，TeamCity 将使用一个与 VCS 根设置中指定的获取 URL 相对应的值。
Bitbucket Cloud
要连接到 Bitbucket Cloud ，请确保 TeamCity 服务器 URL 是一个完全合格的域名（FQDN）：例如， http://myteamcity.domain.com:8111。 短名称，如 http://myteamcity:8111 ，会被 Bitbucket API 拒绝。
对于 身份验证类型 ，您有以下选项：
使用 VCS 根证书 — TeamCity 将尝试从 VCS 根设置中提取凭据。 这个选项是为使用令牌（无论是静态/个人还是可刷新/OAuth）通过身份验证并使用HTTP(S)获取URL来获取仓库的VCS根设计的。 如果相关的 VCS 根使用匿名或标准的用户名-密码认证，或者使用 SSH 获取 URL，请选择其他选项。
用户名/密码 — 指定用于连接到 Bitbucket Cloud 的用户名和密码。 对于 Bitbucket Cloud 团队帐户，可以使用团队名称作为用户名，而 API 密钥作为密码。 我们建议您使用带有 Pull Requests | Read 权限范围的 app 密码。
可刷新访问令牌是由 TeamCity 通过现有的 OAuth 连接从所需的 VCS 提供商获取的短期令牌（与用户在 VCS 托管端手动颁发的静态 PAT 令牌不同）。 有关生成和使用可刷新令牌的更多信息，请参阅以下文章： 管理可刷新访问令牌。
Bitbucket Server
以下参数适用于 Bitbucket Server/Data Center 托管类型：
形参 | 描述 |
|---|---|
Bitbucket Server 基础 URL | 指定 Bitbucket 服务器的基础 URL，格式如下： 如果留空，URL 将从 VCS 根获取 URL 中提取。 |
身份验证类型 |
|
要保护一个分支，并确保只有经过验证的拉取请求才能合并到其中，您可以在您的 Bitbucket 仓库设置中指定 必需的构建。 要将 TeamCity 构建设置为 必需构建 ，请打开 Bitbucket 中的 添加所需的构建 页面，并在 添加构建 字段中指定构建配置 ID 作为构建键。 在这种情况下，Bitbucket 不会允许合并拉取请求，直到请求更改的构建成功完成。
Azure DevOps
为了设置 Azure DevOps 的 Commit Status Publisher，指定您的 Azure 服务器 URL 并选择首选的身份验证方法。
个人访问令牌 或 PAT 是静态身份验证令牌，您可以在 您的 Azure DevOps 帐户设置中生成。 您的发布令牌应具有
代码（状态）和代码（读取）权限范围，以允许 Commit Status Publisher 发布状态更新。 对于 VSTS connections ，可以从连接设置中自动获取令牌。可刷新访问令牌是由 TeamCity 通过现有的 OAuth 连接从所需的 VCS 提供商获取的短期令牌（与用户在 VCS 托管端手动颁发的静态 PAT 令牌不同）。 有关生成和使用可刷新令牌的更多信息，请参阅以下文章： 管理可刷新访问令牌。
JetBrains Space
从2023.11版本开始，通过预设的 Space connections设置的 TeamCity 构建配置不再需要配置 Commit Status Publisher 来发布构建状态。
使用 Space 连接设置项目后，TeamCity 将自动在 Space 的 自动化 部分以及 提交 和 分支 选项卡下发布与构建相关的评论。
也可以手动设置 Commit Status Publisher 功能。 如果满足以下条件，您可以选择手动设置：
您希望设置自定义发布者名称和 / 或 Space 项目密钥；
TeamCity 无法自动发布构建状态（例如，如果您使用具有自定义配置的 JetBrains Space 的本地实例，可能会发生这种情况）。
要手动设置 Commit Status Publisher，您需要预定义的 Space connection。 如果您没有合适的连接，并且您的项目是手动创建的或来自存储库 URL，请转到 项目设置 | 连接 并创建一个新连接。
然后，在构建配置的设置中：
打开 构建功能 并添加 Commit Status Publisher构建功能。
选择 JetBrains Space 发行商和已创建的连接。
指定将在 Space 中为此服务显示的名称。
保存设置。
Perforce Helix Swarm
如果在 Perforce 的 shelved files 中运行构建，TeamCity 可以将其状态以评论形式报告给 Perforce Helix Swarm 中的相应代码审查。
请参阅此帮助文章以获取更多信息： 与 Perforce Helix Swarm 的集成。
Gerrit
Commit Status Publisher 支持 Gerrit 版本 2.6+。 若要配置与早期 Gerrit 版本的集成，请联系我们的 支持。
使用 Commit Status Publisher
将构建功能添加到您的构建配置中。
如果您希望 Commit Status Publisher 尝试为所有已连接的 VCS 根发布提交状态，使用默认的 所有已连接的 VCS 根 选项，或选择一个单一的储存库来发布构建状态。
选择您的系统作为发布者，并指定其连接详细信息和凭证。
测试连接
保存您的设置。
示例：配置 Pull Requests 状态发布至 GitHub
以下示例演示了如何配置从 TeamCity 向 GitHub 发送包含在您的拉取请求中的构建状态更改。
使用 pull requests build feature 来配置 pull requests 分支。 您也可以通过在您的 VCS Root 中配置 分支规范 来使分支可用，同时确保它包括拉取请求分支（也可以参见相关的 博客文章）。
添加 Commit Status Publisher 构建功能：
使用默认的 所有附加的 VCS 根 选项为所有附加的 VCS 根中的提交发布状态。
选择 GitHub 作为发布者，并指定其连接详细信息和凭据，然后测试连接：
保存您的设置。
将源代码的更改提交并在 GitHub 中创建拉取请求，然后在 TeamCity 中使用您的更改运行构建。 Commit Status Publisher 将会向您通报与您的拉取请求更改相关的构建状态：
它将向您展示检查是否为：
进行中
失败
成功
将鼠标悬停在提交状态上会显示构建摘要
点击构建状态图标或 详情链接，将在 TeamCity 中打开 构建结果页面。 此信息也可在您的拉取请求详情的 提交 选项卡中找到。
与上一页面类似，点击构建状态图标会在 TeamCity UI 中打开 构建结果页面：
使用 Commit Status Publisher 与 VCS 检出规则
如果构建的 VCS 根设置了 检出规则 ，那么 Commit Status Publisher 将只考虑符合这些规则的提交。 也就是说，如果构建开始前的最后一次提交不符合检出规则，它将不会被标记为构建状态；状态将显示在最后一次满足提交的旁边。
如果您需要在构建的最后一次提交旁边显示构建状态（例如，在拉取请求中），您可以调整检出规则，以便将此提交纳入 VCS 根的范围内。 或者，如果这是一个经常出现的问题，您可以考虑按照以下方式重新安排您的构建链：
配置主构建的签出规则。
配置一个实用工具 composite build ，不包含构建步骤和检出规则，但包含 Commit Status Publisher 功能。
在复合构建中，为主构建配置一个 快照依赖。
在这种链的范围内，Commit Status Publisher 将不受检出规则的约束，而构建状态将显示在最后一个提交旁边。
故障排查
TeamCity 写入事件与 Commit Status Publisher 构建功能相关到 teamcity-commit-status.log 文件。 将 "debug-commit-status" 预设应用于此日志，以包含 DEBUG 级别的事件。