Can the head_ref and base_ref properties of a GitHub pull request be exposed as TeamCity properties?

We've got a special TeamCity configuration for building GitHub pull requests, using the standard "+:refs/pull/*/merge" refspec on the GitHub repo.

So while that let's our configuration build the pull request, what I'd like to do is access the pull requests source and target branch names to do some special processing / error handling.

If ProjectRepo has pull request 1234 raised to merge FredsFork/feature/FizzBuzzCalculator into ProjectRepo/master, then TeamCity will attempt to build the /pull/1234/merge reference.

I'd like to be able to use the GitHub API to query info about PR 1234, and discover that the base_ref is "master" and the head_ref is "feature/FizzBuzzCalculator"

Specifically, I'd like to use a different checkout directory for different base_refs. We can use incremental builds (under 5 minutes) for all pull requests that target the same branch, but as soon as another PR is raised that targets a different upstream branch, we are forced to do a full rebuild, which adds 40 minutes to our build time.

Right now, TeamCity thinks the name of the branch it is building is

/pull/1234/merge
. I'd like to somehow modify the VCS configuration so that the default agent checkout directory is
head_ref
.

So if I can keep unrelated PRs separate, our PR builds speed up incredibly.

Does TeamCity's GitHub integration have any way of exposing this information for a pull request?
6 comments
Comment actions Permalink

Hi Doug,

sorry for delay. At this time TeamCity doesn't have any GitHub specifics, so all pull request branches looks the same for TeamCity. Feel free to create a feature request in the tracker.

As a workaround you can create dedicated build configuration for each base_ref, detect a pull request's base_ref as first step in the build and if base_ref has a wrong value return exit code 1,so that TeamCity skips all subsequent steps.

0
Comment actions Permalink

We created a feature request https://youtrack.jetbrains.com/issue/TW-43759. Please watch/vote for it.

0
Comment actions Permalink

But if you exit w/ exit code 1, your build will fail because of the non-0 status being returned.  The desired behavior would be to return success at that point, but not run any following build steps.  I suppose you could disable the "the build process exit code is not zero" failure condition, but then how do you prevent the 3rd or 4th build step from running if the 2nd one fails?

0
Comment actions Permalink

I've tried this, but I haven't been able to get it to work properly.

  1. I added a custom script build step at the start of my config that just does an "exit 100"
  2. I disabled the "the process exit code is not zero" failure condition
  3. I set my second build step's "Execute step" to "If all previous steps finished successfully"

Result: when I run the build, the first step returns a 100 status, but the second step runs anyway.  (I tried with "exit 1" as well, with the same results):

 

This is on TeamCity Enterprise 9.1.4 (build 37293)

0
Comment actions Permalink

Hello Andy,

If you want to skip all build steps, then you should enable "the process exit code is not zero" failure condition. 
As another workaround you can check base_ref poperty in the first step and set some TeamCity parameter (flag) using service messages. Then in each step you can check this parameter and skip all actions if for example parameter has false value.

0
Comment actions Permalink

But I don't want to fail the build.  I want it to successfully do nothing by skipping all the build steps after the one that returns non-zero.

It looks like disabling the "process exit code is not zero" failure condition, plus setting each build step to "Execute: If all previous steps finished successfully" should have the desired effect. But it doesn't.

 

 

 

0

Please sign in to leave a comment.