Multiple Optional Snapshot Dependencies

Answered

Hi,

I have multiple build configurations (A and B).

Each of A and B have a build number and a parameter called 'ProjectName'

I want to create another build configuration now called C which will have A and B as snapshot dependencies and then have A and B as multiple Finish Build triggers. (Is this correct?)

I want C to trigger when either A or B finish and pass the ProjectName parameter and build number to C based on what triggered it so I can use it in a build step in C.

I can't find anywhere to do this easily? Is it possible?

Thanks.

1 comment
Comment actions Permalink

Hi Callum,

 

What you want to do is possible and while I'll try to explain how here, there are some caveats to the setup in itself that I'll detail later on.

 

If you have A and B, then C with Finish Build trigger (it's also possible to simply move the A/B triggers to C and remove the finish build altogether since the snapshot dependencies will spawn builds of A and B whenever C is triggered), whenever they are finished C will be indeed triggered and form a chain with them. If you mark the dependencies so that builds can be reused, no new builds will be triggered but the last ones will be reused. If snapshot dependencies and finish build trigger are in place, you don't need to worry since teamcity will make sure to use the correct ones, but still you can move the triggers and reduce the total amount of entities.

 

Once you are at this point, you can simply reference %dep.<id_of_A_or_B>.ProjectName% to obtain ProjectName on A or B from within C, using the ID of whichever build you are using. The problem that arises here is that whether it is A or B triggering C might not be fully clear. You can try to check the "teamcity.build.triggeredBy" parameter for its cause but it would require some parsing to do on a script. While not impossible, it's cumbersome, and gets more complex as this scales out of a small amount of build configuration.

 

One of the major issues with this approach is visibility. One of the most common scenarios where this is requested is, for example, A and B build some (different) components that then want to be deployed in the exact same way via C by using the project name parameter. Once this is setup as discussed above, the problem becomes that then when viewing the results of C, you don't immediately know whether that success or failure corresponds to A or B and have to go deeper looking into it. While it is possible to improve on this, it requires more maintenance and custom scripting. There are some other issues, mostly around reusing and rebuilding but this is typically the easiest to track.

 

The common suggestion for this scenario is to, instead of having a shared C that uses parameters to behave differently when triggered by A or B, have a C-A and C-B separate build configurations (you can use the kotlin dsl or build templates to configure it in a single place so that they are still identical). This allows for A to trigger C-A whenever needed, and B to also trigger C-B, which share the behavior, but you can see on first inspection which of the two happened, failed, etc. It shares the same issues, scaling becoming a problem as you introduce more and more and sometimes multiple can be triggered at the same time, but in that case it typically needs a more detailed discussion with more accurate details. In many instances a restructure of the project can help, not just get this accomplished by standard teamcity means but also improve workflows in general. In some other instances, some scripting is finally required.

 

Hope this helps.

0

Please sign in to leave a comment.