我在 TeamCity 上有我的 CI。目前，它会触发不同事件的构建(Pull Request 创建、 merge 到 Develop 分支等)。但是，我想知道是否可以通过编写特定注释/标记 Pull Request 来触发特定构建。
目标是在Pull Request 已获批准(从编码正确性的角度来看)并且该分支已准备好执行时运行一组自动化 UI 测试 merge 到 Develop 中。我不想为该分支上的每个提交运行那组自动化 UI 测试，因为运行它们大约需要 1 小时，而且我不想仅在 merge 该 PR 后运行它，因此我们避免 merge 任何破坏 UI 的内容测试到 Develop。
所需的流程将是对该 PR 编写特殊注释，例如 run_UI_test 或使用自定义标签标记 PR，以便在 CI 和反馈显示在 Github 上的 PR 上。
非常感谢您。
最佳答案
我不认为 TeamCity 知道 Github 上的评论，因为评论本身没有直接存储在分支中。我的假设是您有一个与此类似的 VCS Root:
+:refs/heads/master
+:refs/heads/develop
+:...
+:refs/pull/*/head
可以通过 GitHub“问题 API”访问 pull 请求的评论，但是，我认为这会给您的构建过程增加不必要的复杂性，并且会掩盖构建是如何被触发的。
我的建议是遵循更传统的 CI 流程，并通过新分支创建另一层“集成”。所以基本上你的流程应该是这样的:
- master( merge pull 请求以发布)
- 集成(运行 UI 自动化测试)
- 开发(运行基本的单元测试和其他东西)
所以基本上所有的开发都发生在 develop 或其他一些“功能”分支上。当所有基本测试都通过并且您准备好“升级”时，您可以 merge 到 integration 分支，这将触发您的 UI 测试。我还想指出，这个“集成”分支实际上可能只是“pull 请求”，实际上不需要静态分支，具体取决于您的开发流程设置。
在 TC 中设置触发规则和分支过滤器比编写一些自定义 REST API 脚本来使用 GitHub Issues API 要容易得多。
关于android - Github 对 pull 请求发表评论的 TeamCity 触发器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34416556/