Seeking for help with setup multiple trigger for a failed configurations

Hi,

Thanks for the advice.

I'm looking to implement a workflow where I can manually trigger builds for all configurations at once, rather than having them triggered automatically. Ideally, I want a single configuration that triggers all subprojects under it, retaining the individual settings of each subproject but with a specific parameter change that will be passed to all subprojects.

Is it possible to achieve this in Kotlin DSL? If so, could you provide some guidance or examples on how to set this up?

Thank you!

Hello Anton,

Yes, using snapshot dependencies seems to work, but I can't figure out how to change or pass parameters from the single trigger to the snapshot dependencies. Do you know how to do this?

Thank you!

Thank you for the response.

The first approach using shared parameters in the build chain seems more suitable for us, as the second approach won’t work due to our inability to ensure builds run on the same agent.

However, I’m not entirely clear on the example provided in the build chain link:

TAG=v1 docker build -f Dockerfile --tag your.registry/MyApp:${TAG} docker push your.registry/MyApp:v1 echo "##teamcity[setParameter name='DockerImageName' value='MyApp:${TAG}']"

Where should this be added?

We use a default template for all build configurations. Could you guide me on where to put this build step from the example? Additionally, how can I define a simple variable, such as 'Product version,' with a value specified manually in the main configuration, and then pass this variable to the snapshot dependencies using the provided example? I do not understand exactly what parameters like TAG, your.registry/MyApp, and DockerImageName mean in this context.

Thank you!

Hello Anton,

Do I need to use the line

TAG=v1 docker build -f Dockerfile --tag your.registry/MyApp:${TAG} docker push your.registry/MyApp:v1 in the build step of the build configuration to be able to use `%dep.ConfigA.DockerImageName%` in the build chain, or is the line

echo “##teamcity[setParameter name='DockerImageName' value='MyApp:${TAG}']” with my own parameter/value sufficient?

I am asking because I've already tried this approach and I could not see any parameter that I defined this way in the ConfigA build configuration when I typed `%dep.` in the TeamCity UI to trying to find out, that the params could be really accessed.

Additionally, when you mention a static value, do you mean a value hardcoded in the ConfigA parameters, or does it also include a value set through the UI custom menu in TeamCity?

Best regards,

Josef

Dear Josef,

Could you provide more detail on what is not working for you?

As an example, I created a build parameter in the first build configuration:

And I can access it in subsequent configurations in the build chain:

The documentation shows a real-life example that builds and pushes a Docker image. It saves the name of this image to the DockerImageName parameter to use in subsequent build configurations. You don't need to run Docker commands to just save the new value to the created parameter.

Best regards,
Anton

Hello Anton,

I figured it out with the help of my colleague. I had initially set up the dependencies in the opposite way, with ConfigA depending on ConfigB, ConfigC, etc., which is why the %dep. reference didn't work. I thought I had to set it up with a top-down hierarchy, which led me to assume that the first way was correct.

I switched it so that now each subproject (ConfigB, ConfigC, etc.) has dependencies set up to ConfigA. With this setup, the %dep. reference is working well.

Thank you for your assistance!