One push to git triggers many builds

We have a situation where each developer has their own fork in GitHub and TeamCity watches each fork for changes.  TeamCity pushes changes to the repository from which each developers repo was forked if the forks build is successful.  However if  developer A pushes changes to his fork which contain changes from Dev B, Dev C and Dev D as well then team city seems to schedule multiple builds, one for each contiguous set of developer builds.  this is not what we want, what we want is a single build of that tip of the repository and thats it.

Is it possible to configure this to happen?

9 comments
Comment actions Permalink

Hi Sam,

please clarify: do you use a separate build configuration for each fork? What triggers do you use? How TeamCity pushes changes? Is it a separate build step?

0
Comment actions Permalink

The issue was a misunderstanding I think.   We had checked the 'Build on each checkin' when actually we didn't need this to be checked.  removing the check makes TeamCity bnuild only once for each push.

0
Comment actions Permalink

But could you explain how TeamCity 'push' to remote repository/branch? I'm looking for this feature with no luck.

I would like to set up something similar to yours environment.

1. I would like to set up private central Git (Gitorious)
2. Each Developer will have read permission to master branch of the project
3. Each developer pulls changes from master and push them to his own clone/fork (maybe just branches, I havent' decided yet).
4. TeamCity monitors each cloned repository and fires Build + Tests on each commit.
5. When Build + Test Pass, TeamCity pushes changes to project's repository 'quality-assurance' or just separate branch.
6. When QA check the code they can manually fire production build or something like that, and TeamCity builds everything push changes to master and deploys application.

It's just a plan and I don't know if it will work as I wish. I haven't figured out everything yet and right now I'm trying to configure teamcity to push changes to separate repostiory or separate branch. So your explanation would be really helpful.

0
Comment actions Permalink

Hi Simon,

we implemented a very similar workflow using github and teamcity.  Details can be found in my answer on this stackoverflow question.

There were some issues with this in teamcity, as the build steps do not always respect the 'only if all previous steps were successful' condition for when they should execute and so you have to set up several builds which are chained together via snapshot dependencies, and whilst the build steps themselves can be templated, the dependencies can't be which means its quite a bit of effort to set up the build chains for every developer, especially in our case where the builds will build and run unit tests, package and deploy to Azure, then run some post deployment tests on the deployed instance and only then do we do the 'push to green' step.  Anothewr thing to consider is if you are going to set your main git repository to only accept pushes which are fast forwards.  We originally did not do this, but found that this left us open to accidental forced pushes (which we are not sure how they happened, but forcing the green repository to only accept fast forward pushes fixed the problem for us.

Good luck!

0
Comment actions Permalink

Hi Simon,

TeamCity itself doesn't push to remote repository at this time (please watch/vote for http://youtrack.jetbrains.com/issue/TW-16054). You can use a command line runner executing 'git push origin' as a last build step in configuration with flag 'only if all previous steps were successful'. That means you should use an agent-side checkout,because with server-side checkout there is no '.git' on the agent, so push won't work.

In TeamCity 7.1 we added a special support for feature branches (http://confluence.jetbrains.com/display/TCD7/Working+with+Feature+Branches). It is a lot easier to implement your workflow using branch per developer or feature rather than fork per developer/feature. With feature branches you don't have to create a build configuration for each developer, a single build configuration watches multiple branches, so there are no problems with snapshot dependencies pointed by Sam.

0
Comment actions Permalink

I don't know how much you have used this Dimity, but having looked at this in detail over the last few months I can say, that much as I would love to be able to add a build step at the end which invoked the push to green repository, this will NOT work due to this bug at least, which means that you can end up pushing code that fails unit tests as the step which does that does not stop the build from running.  There are other issues around bugs in powershell scripts which also don't fail the builds which also caused us issues, and forced us to introduce the extra complexity of the snapshot dependencies.  I was hoping that these would be fixed in the last couple of releases, but alas it hasn't been

0
Comment actions Permalink

Hi Sam,

I wasn't aware of such bugs, since I mostly use java. As I understand you have extracted a 'git push' step into a separate build configuration which has a snapshot dependency on the initial build configuration, right? This indeed complicates a workflow.. But it is easier to implement it with TeamCity 7.1 anyway. I hope the bugs you've mentioned will be fixed soon.

0
Comment actions Permalink

Me too! :).  yes we have 4 builed steps each connected by snapshot dependencies.  the 'push to green' triggers a deployment + postdeployment tests, which triggers a package and pre deployment setup, which triggers a build of the developers personal fork.  So it is quite a bit of effort to set up a new developer, but as I said we have templates which make this process simpler.

0
Comment actions Permalink

Thx for the answer. I knew it wouldn't be so easy ehm... I'm a bit worried about so many build configurations. I'm just starting to implement CI solution at my company and if I will be forced to create so many build configurations, just to implement this workflow I don't know if it's worth it. Enterprise edition would be too expensive and I will have to change my mind and grab Jenkins ehm...

Right now I'm doing just a proof of concept, but noone will be happy if I will tell them, that they have to pay ~2000 USD, just because workflow needs so many builds. Maybe it could be relaxed in some way. I have to think out something.

How many devs do you have? What TeamCity edition do you have? and finally how many build configurations do you have in your environment?

0

Please sign in to leave a comment.