Github的TeamCity触发器对拉取请求的评论 [英] TeamCity trigger for Github comment on pull request

问题描述

我在TeamCity上拥有自己的CI。当前，它在不同事件上触发构建（ Pull Request 创建，合并到 Develop 分支等）。但是，我想知道是否可以通过编写特定注释/标记 Pull Request 来触发特定构建。

目标是在批准 Pull Request 后（从编码正确性角度出发）运行一组自动化的UI测试。的视图），该分支已准备好合并到 Develop 中。我不想为该分支上的每个提交运行这套自动UI测试，因为运行它们大约需要1小时，并且我不想仅在合并该PR后才运行它，因此我们避免合并任何会破坏UI的东西测试进入 Develop 。

所需的流程是在诸如 run_UI_test 之类的PR或使用自定义标签标记PR，以便在CI上执行测试，并在Github的PR上显示反馈。

非常感谢。

解决方案

我不认为TeamCity有任何意识在Github上发表评论的数量，因为评论本身并不直接存储在分支中。我的假设是您有一个类似于以下的VCS根：

  +：refs / heads / master 
 +： refs / heads / develop 
 +：... 
 +：... refs / pull / * / head 
  

可以通过GitHub问题API访问请求请求的注释，但是，我认为这会给构建过程增加不必要的复杂性，并且会掩盖如何触发构建。 / p>

我的建议是遵循更传统的CI流程，并通过新分支创建另一层集成。因此，基本上您的流程应如下所示：

• master （合并发布请求请求）


• 集成（运行UI自动化测试）


• 开发（运行基本单元测试和其他功能）

因此，基本上所有开发都发生在 develop 或其他功能分支上。当所有基本测试通过并准备升级时，您可以合并到 integration 分支中，该分支随后将触发您的UI测试。我还想指出，这个 集成分支实际上可能只是拉请求，实际上不需要静态分支，具体取决于您如何设置开发流程。

在TC中设置触发规则和分支过滤器要容易得多，那就是编写一些自定义REST API脚本以与GitHub Issues API一起使用。

I have my CI on TeamCity. It currently triggers builds on different events (Pull Request creations, merges into Develop branch, etc.). However, I was wondering if it is possible to trigger a specific build as a result of writing a specific comment/labelling a Pull Request.

The goal is to run a set of Automated UI tests when a Pull Request has been approved (from a coding correctness point of view) and that branch is ready to be merged into Develop. I don't want to run that set of Automated UI tests for every commit on that branch as it takes around 1h to run them and I don't want to run it only after merging that PR so we avoid merging anything that breaks the UI tests into Develop.

The desired flow would be to write a special comment on that PR such as run_UI_test or labelling the PR with a custom label so the tests are executed on CI and the feedback is displayed on the PR on Github.

Thank you very much in advance.

解决方案

I don't believe TeamCity has any awareness of the comments on Github since the comments themselves aren't stored directly in the branch(es). My assumption is that you have a VCS Root similar to this:

+:refs/heads/master
+:refs/heads/develop
+:...
+:refs/pull/*/head

It is possible to access the comments of a pull request through the GitHub "Issues API", however, I think this would add unnecessary complexity to your build process and it would obscure how the builds are getting triggered.

My suggestion would be to follow a more tradition CI process and create another layer of "integration" through a new branch. So basically your flow would look like this:

• master (merge pull requests for release)
• integration (Run UI automation test)
• develop (Run basic unit tests and other stuff)

So basically all of your development happens on develop or some other "feature" branch. When all basic tests are passing and you are ready to "promote" you could merge into the integration branch which will then trigger your UI tests. I also want to point out that this "integration" branch could in fact just be "pull requests" and no static branch is actually required depending on how you have your development flow setup.

it's much easier to setup trigger rules and branch filters in TC then it would be to write some custom REST API script to work with the GitHub Issues API.

这篇关于Github的TeamCity触发器对拉取请求的评论的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！