How to report the build status to GitHub PRs when the build is skipped due to trigger rules

Avatar
Stephan Grimm
Created

Hi TeamCity community,

in our project we'd like to use build trigger rules to (this is just one example) avoid running the build if only markdown files change.

The part of defining the trigger rules which don't trigger the build was easy.

The problem we now have is that if the build is not triggered anymore also the build status is not reported anymore to the GitHub Pull-Requests.

Since we have defined a "branch protection rule" with some mandatory builds to pass before the merge is possible, the merge wont be allowed ever (if the build is skipped by trigger rules).

Any suggestion how to solve/workaround that?

Votes

0

Share

3 comments
Avatar
Fedor Rumyantsev
Created

Hello Stephan,

Unfortunately, if there is no build then Commit Status Publisher feature never triggers. I can think of two possible workarounds:
1) you may use build step execution conditions so that the build always starts but the actual build steps are executed only if there are relevant changes (the downsides are that the build takes the agent and makes a request to the VCS so as to fetch the changes; also, you would need some logic to resolve the changes associated with the revision build runs on);
2) you may also use GitHub API to report statuses for the revisions which are not built.

Please let me know if that helps.

0
Avatar
Stephan Grimm
Created

Hey @...

Thanks for your fast response. Your ideas sound interesting.

I played around with approach 1) the last days:

  1. Build step #1 checks if commit is relevant (for example ignore docs)
  2. Following build steps skipped with "build step execution conditions"

I face one issue I could not fix so far.

  1. A #1 commit lead to a successful build --> success reported to GitHub
  2. A #2 commit lead to a failing build --> failed reported to GitHub
  3. A #3 commit changes a doc file only. In this case I skip all the build steps and return success to GitHub.
    If I do so, the status is success, but should actually be failed because the real changes (#2) lead to a failing build before.

Any suggestion how to fix this?

I had one idea, but not yet implemented:
If I could easily retrieve the full change set of a TeamCity build configuration (of the current branch) I could also do my filtering based on the full GIT change set and not on single commits only.

0
Avatar
Fedor Rumyantsev
Created

Hello Stephan,

Sure, you may access the changes via REST API:

/app/rest/changes?locator=buildType:<build configuration ID>

but I could not find a way to filter them by the branch. Would that help?

0

Please sign in to leave a comment.