Project added to build queue multiple times

Answered
Avatar
richardboyce
Created

We have a base set of common components - e.g. Logging, Auditing

We have a number of products that consume those components - call it Arrow. I have built all the common components as subprojects in a 'Common Components' TC project. The Arrow product builds if any of it's code changes (VCS triggers) OR if any of the components it depends on builds.

In the Arrow project, there is a subproject that builds Arrow.Base (build  finished trigger on CommonComponents.Auditing). There is another project - Arrow.Artichoke - that depends on Arrow.Base AND on CommonComponents.Logging.

For Arrow.Artichoke, I added 'finish build trigger) on CommonComponents.Logging and Arrow.Base.

What happens is that CommonComponents builds everything and adds Arrow.Base to the build queue as a result of Auditing build completing) and adds Arrow.Artichoke to the build queue as a result of Logging build completing. When Arrow.Base builds, it again adds Arrow.Artichoke to the build queue. So now I have 2 Arrow.Artichoke builds in the queue.

How can I stop that?

Thanks

Richard

Votes

0

Share

2 comments
Avatar
Eric Borchardt
Created

By default, the TeamCity build queue is optimized in the following ways (Build Queue Optimization):

  • If a similar build exists in the queue, a new build (on the same change set and with the same custom properties) will not be added
  • If an automatically triggered build chain has more changes than a build chain that is already queued, the latter will be replaced with the automatically triggered build chain, if such replacement will not delay obtaining the build chain results (based on the estimated duration)
  • While a build chain is in the queue, TeamCity tries to replace the queued builds with equivalent started builds
  • Builds that have been staying in a queue for longer than 15 days are canceled automatically (for example, if there are no compatible agents).

Please note that this default behavior can be manually disabled via the corresponding option in the VCS Build Trigger and Schedule Build Trigger.

Your use case sounds like a good opportunity to use a build chain, utilizing snapshot dependencies instead of finish build triggers. Do you currently have these builds configured with snapshot dependencies? If so, would you mind sharing some screenshots of your build chain charts for your Arrow projects so that I can better understand how things are related?

0
Avatar
richardboyce
Created

Hi Eric, thanks for the response. I have another (https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360009487900-Infinite-loop-on-builds-and-general-understanding-of-build-order-and-priorities?page=1#community_comment_360002131439) post which you also replied. I'm not using build chains as to my (maybe old-fashioned way of thinking), they work 'the wrong way round'.

Maybe your answer to a comment on that post will also clear this up.

I certainly saw multiple builds of the same projects in the build queue. The queue didn't seem to obey the rules about priorities and optimisation.I was very careful about making sure there were no circular dependencies and checking after the fact, I didn't see any.

I've made changes to fix the problem, but it means I'm not using the features of TeamCity to their fullest, so I'd like to get my understanding straight

Regards

Richard

 

0

Please sign in to leave a comment.