我在TeamCity上有我的CI。它目前触发不同事件（Pull Request创建，合并到Develop分支等）的构建。但是，我想知道是否可以通过编写特定注释/标记Pull Request来触发特定构建。
目标是在批准Pull Request时（从编码正确性的角度）运行一组自动UI测试，并且该分支已准备好合并到{ {1}}。我不想为该分支上的每个提交运行那组自动UI测试，因为运行它们需要大约1小时，我不想在合并该PR之后运行它，因此我们避免合并任何破坏UI的内容测试Develop。
所需的流程将是对该PR撰写特殊评论，例如Develop或使用自定义标签标记PR，以便在CI上执行测试并显示反馈在Github的公关上。
非常感谢你。
答案 0 :(得分：1)
我不相信TeamCity对Github的评论有任何意识，因为评论本身并不直接存储在分支机构中。我的假设是你有一个类似的VCS Root：
+:refs/heads/master
+:refs/heads/develop
+:...
+:refs/pull/*/head
可以通过GitHub“Issues API”访问pull请求的注释，但是，我认为这会给构建过程增加不必要的复杂性，并且会模糊构建的触发方式。
我的建议是遵循更传统的CI流程，并通过新的分支创建另一层“整合”。所以基本上你的流程看起来像这样：
所以基本上所有的开发都发生在 develop 或其他一些“功能”分支上。当所有基本测试都通过并且您已准备好“提升”时，您可以合并到集成分支，然后该分支将触发您的UI测试。我还想指出，这个“集成”分支实际上只是“拉取请求”，实际上不需要静态分支，具体取决于您的开发流程设置方式。
在TC中设置触发器规则和分支过滤器要容易得多，然后编写一些自定义REST API脚本来使用GitHub Issues API。
答案 1 :(得分：0)
您可以通过设置单独的构建配置来实现类似的功能，该配置使用特定的VCS触发器来运行UI测试。此构建配置还将具有不同的构建步骤，其中包括执行测试的命令。
例如：在触发器中，您可以使用+:comment=presubmit:**添加一个新的VCS触发器。它将查找包含“ presubmit”的任何提交消息，并触发您的UI测试套件运行。
我已经看到一些存储库使用诸如https://danger.systems之类的工具来编写自定义规则，这些规则可以在Github注释中查找文本并基于该注释触发交互。