TeamCity 7.1 feature branch & Github service hook. What's the right way?

Current Version: TeamCity Enterprise 7.1.1 (build 24074)

Pre 7.1 we had 3 build configurations for each project.  Each config specified a different branch for check out from the VCS (Git/Github): master, staging, development.

In Github, we had a TC service hook pointing at the config for the "development" branch (where the most commits take place).  We also had TC set up to poll the VCS for changes every 15 minutes to pick up changes to any other branches.

The downside of this configuration is that a commit to "master" or "staging" branches would trigger an uncessary run of the "development" branch in TC, but the 15 minute polling detected changes to the modified branch and added it to the queue as well.  This wasn't a big problem for us given our workflow.

Post 7.1 we've been struggling with the proper configuration for the VCS, build configuration, and Github TC service hook.  We now have one build configuration for each project and (as before) a single VCS configuration.  The repo name in the VCS config is populated from an attribute we specify per-project.  Our Github service hook settings have not changed.

Our hope was that with the new feature branch changes in 7.1, the Github service hook would fire and pass along to TC the branch that needs to be run.  TC would check out the appropriate branch, run the tests, and all would be good.  That's not what is happening.

The root of our problem seems to be this: the Github TC service hook sends a partial branch name (e.g. "staging") rather than the full branch name, "refs/heads/staging".  The partial branch name always trigger a run of the default branch, "master" (as specified in the VCS configuration), rather than the modified branch.  This seems to be the case no matter what we put in the "Branch Specification" configuration of the VCS -- even a wildcard * has no effect.

For example, let's say I commit a change to the "development" branch.  This will trigger a run in TC via the Github service hook.  IN TC the run will show up with a label of "development" next to it in blue.  Unfortunately, when we look at the code that was checked out, the default branch (master) is what was checked out and run.  If we wait for the 15 minute VCS polling, TC will detect the changes to the development branch and queue up a run.  This run is labeled "refs/heads/development".  For this run, the development branch is checked out and everything looks good.

I've been pulling my hair out trying to figure this out.  Has anyone else had any issues or any insight?

2 comments
Comment actions Permalink

I had the same issues. 8.0 version not fixed it.

0
Comment actions Permalink

Alexander,
Please check my reply below and if yours is different, please detail your case from scratch in the issue posted ( http://youtrack.jetbrains.com/issue/TW-30609 )

John,

It's probbaly too late for an actual reply, sorry for that.

Anyway:
The main issue seems that the hook triggers a build in TeamCity on a branch, but that build actually gets changes from the TeamCity-configured default branch, not the one updated.

If this is accurate, then it seems a configuration issue:

Checking the code of GitHub TeamCity hook, it seems it adds "&branchName=<branch>" into the URL, where "<branch>" is the branch name without the first two levels: <refs>/<heads>/<branch>
That imposes a constraint on how feature branches are configured in TeamCity. Namely, branch specification of the Git VCS root should most probably be: "+:<refs>/<heads>/(<branch>)" (note the parentheses around <branch>).

Would be great to check this and if appropriate setup does not help, get full details on the TeamCity settings and how does this isue look in TeamCity (Changes tab of the build triggered and the build manually run on the changes, etc.)

0

Please sign in to leave a comment.