dep parameter without explicitly specifying the project id?

Is there a way to refer to parameters of the dependency without having to specify the dependency project ID in the artifact dependency path?

For example:
- Root project A creates a zip file using something like "%MY_CUSTOM_FILE_PARAM% =>"
- Project B has an artifact dependency on A (last successful build).

As an Artifact Path I could write "!%dep.A.MY_CUSTOM_FILE_PARAM%".
However, I was wondering as the the direct dependency is already specified by the "Artifacts Source" if I couldn't write something more generic like"!%dep.MY_CUSTOM_FILE_PARAM%" at this location?

Comment actions Permalink

Hi Hans,

No, it is not possible. The build configuration Id is explicitly defined if one dependency is configured, while It's the generic form for the case of multiple dependencies.

Comment actions Permalink

Hi Alina,

Ok, basically this means that there is no way for a template to define the dependency path without knowing the full dependency on template level?

I'm faced withing having to specify complex dependency paths in our test configurations, which have a build-up as following:

Any suggestion to limit the artifact configuration duplication?

Comment actions Permalink


Sorry for delay. No, it is not possible to define the dependency path on template level. The current solution is to change dependencies manually.
Also you can create a project with number of build configurations and configure needed dependencies and parameters. If you copy this project, TeamCity automatically assigns a new name and ID to the copy. Build configuration IDs in dependent parameters will be replaced correspondingly.
It is not possible to create project templates, please vote for the related feature requests,

Comment actions Permalink


I don't think TW-3287 is related.
However, TW-40405 comes close. But what would be nicer is that the redundant information in the specifying artifact dependencies and artifact paths is removed, or that the build ID is just optional in this case.
After all, it is a source of error in having to specify the the artifact project and in more advanced artifact dependency path specifications having to specify the artifact project id path again.


Please sign in to leave a comment.