GitHub Checks Webhook 触发器
常见信息
GitHub Checks Webhook 触发器 会在新的更改推送到远程 GitHub 仓库时运行 TeamCity 构建。 此外，此触发器会将详细的构建结果信息发布到 GitHub。
如果处理过的更改集是拉取请求的一部分，则该请求会在其“检查”选项卡上显示相同的构建结果信息。
如果您不希望公开您的构建服务器地址，请在触发器设置中勾选 在 GitHub 检查运行输出中禁用 TeamCity 链接 选项。 在这种情况下，构建状态消息将不会发布链接到 TeamCity 构建和构建日志。
该触发器利用 GitHub Checks API ，可以作为唯一的提交验证机制，或补充原生 GitHub Actions 工作流。
限制和要求
GitHub Checks Webhook 触发器 仅与那些使用可刷新令牌访问版本控制系统的 VCS 根的构建配置兼容。 这些令牌是通过 GitHub App 连接发出的。
连接必须启用其 支持 Webhooks 选项。 此外，触发器要求相关的 GitHub App 具有
检查：读和写权限并处理检查运行和检查套件webhook 事件。 如果您使用“自动”模式配置新的 GitHub App TeamCity 连接，则所有必需的权限和 webhook 事件处理程序都将已经启用。 否则，如果您以“手动”模式配置新连接，或希望更新在 2024.07 版本之前创建的连接，请在 GitHub 端相应地修改您的 App 设置。 您还需要重新获取一个 auth token ，以使更新的权限生效。如果相关的 VCS 根目录启用了 Use tags as branches选项，则在创建新 tagged release时，GitHub Checks Webhook Trigger 不会自动启动新的构建。
在一个构建配置中同时使用 GitHub Checks 和 标准 VCS触发器可能会导致对同一个推送触发重复的构建。 请考虑只使用一个触发器，以避免过多的构建。 如需了解更多详情，请参阅此 YouTrack 工单： TW-88928。
比较 Checks 和 VCS Triggers
在“经典” TeamCity 设置中，自动变更构建配置如下：
TeamCity 从远程代码库中收集新的更改。 这可能在自动 轮询期间发生，或者如果配置是通过现有的 GitHub App 连接创建的，当 GitHub 向 TeamCity 发送 post-commit webhook 时会发生。
VCS trigger 根据其自己的计划检查待处理的更改，如果有一个或多个新提交可用，则生成一个新的构建。 触发计划保护 TeamCity 免于生成过多的构建，这是在提交频率非常高的情况下可能发生的。 相反，它提供了一种平衡的方法，构建可以成批处理新提交。 例如，所有在过去五分钟内推送的提交将导致一个 TeamCity 构建。
如果配置了 提交状态发布器 功能，则构建状态会传回 GitHub。
与此设置相比， 检查触发器 展示了以下主要差异：
它没有内部计划，并确保每次新的推送都会生成一个新的 TeamCity 构建。 这种机制适用于需要为每次推送生成构建的情况，无论推送的频率如何。
它不需要一个 提交状态发布器 来发布Markdown格式的状态更新。