0

I'm trying to setup a pipeline for running all kinds of tests against pull requests into my repository. Repository is git repo hosted with Bitbucket Server and TeamCity is Enterprise 2019.1.5 (build 66605). There are a few key aspects to the task:

  1. There's a lot of tests. One way or the other tests should run in parallel to achieve reasonable execution time. The tests are already partitioned as separate TeamCity build configurations, each having good enough execution time.
  2. There's much less build agents available for the task, so it's not impossible for a particular build to spend quite some time (up to 1-2 hours) in a build queue.
  3. The result of the testing should be reported to Bitbucket as a single aggregate value. I.e. if there are, say, 3 individual builds from p.1 with two passing and one failing then Bitbucket should receive single "failed" build status.
  4. Ideally, pipeline should be triggered by a feature branch change (refs/pull-requests/123/from in Bitbucket lingo), but checkout merges of the feature branch into target branch (refs/pull-requests/123/merge in Bitbucket lingo).

Given above requirements, I experimented with Composite Build Configuration (https://www.jetbrains.com/help/teamcity/composite-build-configuration.html) as it seemed perfect fit for the job. So I set up single composite build with proper builds from p.1 as snapshot dependencies, "Pull Requests" and "Commit status publisher" build features. It works perfectly, except for one thing...

The only thing I cannot seem to be able to work around is the fact that VCS roots in the dependencies collect changes when the build chain is added to the build queue. This means that because of p.2 (non-negligible max time spent in build queue) some builds end up running against a little bit dated sources. Ideally, I would like to be able to run the builds against the latest sources.

So my question is if there's any way to disable revision synchronization for dependencies? Or maybe I could approach the whole problem in some completely different way without using snapshot dependencies?

Cross-posted at community forum: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360006745840

Ilya Kurnosov
  • 3,180
  • 3
  • 23
  • 37
  • The setup you describe seems to require revisions synchronization, otherwise there is no single state to report to Bitbucket. BTW, if the second chain is put into the queue while the first one has not yet started, only the later one should be build (currently, composite builds can prevent it, but it will be addressed: https://youtrack.jetbrains.com/issue/TW-51742 ) – Yaegor Dec 09 '19 at 09:44
  • The tradeoff you seem to highlight is: (a) having all the builds correspond to single version (in broad sense) of sources; vs (b) having some of the triggered builds running against version of the sources that's known to be stale at the time the build starts. I'm aware of it, and my preference is (b). Of coures, in ideal world I'd prefer not to have such a tradeoff in the first place. The big question is: How could I do that? – Ilya Kurnosov Dec 09 '19 at 22:35

0 Answers0