Passing parameters dynamically between configs in Many to One Scenario.



I have 3 parent build configs P1, P2 & P3  and one child build config C. After each build of any of the parent build configs, the child build config C should run. For this currently I have thought of configuring finish build triggers in C pointing to P1,P2 & P3. 

My concern is, when build config C is running it needs configuration parameters, configuration build id etc. of the parent build config (any of P1, P2, P3) which lead to triggering of build config C.

eg. If build config Px (where x = 1 or 2 or 3)  was triggered by user, then after it's completion build config C will be triggered. For the successful completion of build config C, I need parameters from build config Px in build config C. 

How can I implement this?

1 comment
Comment actions Permalink


I'm afraid that currently, it's not possible to configure it exactly as you've described, although there is a workaround. The reasons why the described approach isn't going to work are:

  1. To refer to P's parameters from C, you need a snapshot or an artifact dependency on all P configs in config C. That when C runs, it might trigger Px if it has pending changes, or try to download artifacts from all P, even if the build that triggered C was Py and not Px.
  2. Currently, multiple builds of C triggered with Finish Build Trigger by different P configs around the same time can get consolidated into one C build. In other words, currently, Finish Build Trigger doesn't guarantee a one-to-one correspondence between the time it goes off and the number of C builds that will run. Here's a related issue in our tracker: TW-19836.

What I would recommend as a workaround is to set up one C config for each P. Add a snapshot dependency on P to C and trigger C instead of P. If originally you wanted to trigger Px when there are new changes in the respective Px repository, you can attach Px's VCS root to Cx and disable automatic checkout in Cx (Version Control Settings > Checkout mode: Do not check out files automatically). Then remove the VCS Trigger in Px and add it to Cx.

To reduce the overhead of managing multiple C configs instead of one, you can attach all C configs to the same build configuration template or even program it with an extension function in Kotlin DSL (which can be an even better approach if you are willing to invest a small bit of time into getting familiar with the DSL).

I hope this helps!



Please sign in to leave a comment.