2
votes

We are using a private GitHub Organization as version control. When a task is assigned to a developer, they fork the primary repository, make their code changes, and submit a pull request to have the changes merged into the master branch of the primary repository.

We are also using TeamCity for CI. It is currently configured to kick off a build for a VCS commit, which builds, tests, and deploys the artifact to an artifact repository internally. To accomplish this, the Team City build configuration has multiple VCS roots installed; one for the primary and 1 for each developer's fork.

The problem is that Team City pulls from all of them when a commit is made assuming they are all necessary for the build instead of allowing you to only pull from the single repository that triggered the build. Any thoughts on how we can accomplish this without having to create n build configurations in Team City for each project (where n == number of developers working on a project)?

2

2 Answers

2
votes

I see way to do this with preserving current workflow is turning off automatic checkout (VCS Checkout Mode), and checking out code manually in an additional command-line build step, with a parameter %teamcity.build.branch% (logical branch name). I.e.:

git clone ...
git checkout %teamcity.build.branch%

Triggers will just start the job if there are changes in developer's VCS root, fulfill branch env variable; no automatic checkout will happen and then build step will check out only needed branch. Only works with one git URL.

0
votes

After posting in the JetBrains forums, I was pointed to a blog that answers my question.

TL;DR: my approach of using feature branches does not work with GitHub's workflow. Instead, Forks and Pull Requests should be used. The blog referenced shows how you can use Team City to trigger off of a Pull Request. Simply add +:refs/pull/*/head to "Branch Specification" in your VCS Root and all pull requests to the Source repository will trigger your Build Configuration.