No compatible agents in build chains due to parameters from other builds.


We have a build chain, the first build configuration in our chain is in charge of providing a number of paramters to builds that depends on it.

This causes all subsequent builds to list no compatible build agents, not this is not true as ones the first build is run, suddenly there is compatible agents as the "missing" parameters are now available.

Is there ANY way in teamcity to tell Teamcity that this parameter will actually be provided by one of the build configurations it depends on so that it's easier to debug cases where a change suddenly means that there is in fact no compatible agents. E.g. because we bumped a version of a tool or something else?

Comment actions Permalink

Hi Jens,


Is there any reason that you cannot create those parameters by default in your initial build and give them a default value (be it an actual value or simply an empty string)? This is the way teamcity uses to make the rest of the builds know that they have access to those parameters.


For your situation to occur, you don't have those parameters defined, then use the "setParameter" service message within your build to give them values, is that correct? In this scenario, the builds do not have access to the %dep....% parameters and thus get stuck in the queue as you experienced. Under some narrow circumstances it might not be desired that this parameters are known for every build down the chain, but that usually means that the initial build should be split into smaller builds that generate the appropriate parameters only for those down the appropriate chain and not extra stuff.

Comment actions Permalink

Hello Denis and thanks for the answer.

The problem is likely more that I am not sure exactly how or where to do just that.

So, to outline it a bit more which may help in assisting, we have:

Generate Version built configuration which runs a node script that logs the following:
console.log(`##teamcity[setParameter name='semver' value='${semver}']`);

to set the parameter.

Then builds that depends on that uses that information to label assemblies, release notes etc. 

Should i set a parameter on that build configuration in the parameters tab, and which kind or should it be the parent project or?

Comment actions Permalink

Hi Jens,


You are right, it should go into the parameter section of the build configuration. The type should be regular configuration parameter (any other will add a prefix making it not match). Any parent project would also work as parameters are inherited through the project hierarchy, so if this parameters would be shared through multiple configurations on different projects it might make sense to simply add it to the parent project they have in common.

Comment actions Permalink

Cheers for the help.

Seems to work in they way we wan't.


Please sign in to leave a comment.