Issues with Build Chain Configuration Using Different VCS Roots

Avatar
RJ
Created

I am encountering issues with a build chain configuration where B depends on A, and both are using different VCS roots. Here is my current setup:

  • A and B are using different VCS roots.
  • A is added as a snapshot dependency of B, with or without Enforce Revisions Synchronization enabled.
  • A is also added as a finish build trigger of B.
  • B accesses dependency parameters from A using the dep.<btID>.<parameter_name> syntax, with some dependency parameters from A being used as configuration parameters of B.

However, I have encountered 2 issues with this configuration:

  1. When triggering B, A runs first due to the snapshot dependency set, followed by B. However, due to the finish build trigger, B runs a second time, resulting in B running twice and A running once. I do not expect this behavior and would prefer that both A and B run once.

  2. Enabling Enforce Revisions Synchronization with snapshot dependency set causes B to not retrieve dependency parameters from A. As a result, configuration parameters with dependency parameters as default values are left empty after the build finishes. This issue does not occur when Enforce Revisions Synchronization is disabled.

I have not encountered these issues with a build chain that only involves a single VCS root. Therefore, I suspect these issues are due to using different VCS roots. I would appreciate any advice from experienced users on how to resolve these issues.

If you require any additional information regarding my configuration, I would be more than happy to provide it.

Votes

0

Share

7 comments
Avatar
Anatoly Cherenkov
Created
Hi! Could you clarify what the purpose is of adding a finish build trigger to B with A as the watched build? The behavior you described is exactly what should happen, so the purpose of such a trigger configuration is unclear to me.

As for the second issue, the Enforce Revisions Synchronization option only has an effect when you promote a build of A to the configuration B (details: https://www.jetbrains.com/help/teamcity/2022.10/snapshot-dependencies.html#enforce-rev-sync). Likely, empty parameters are the result of some other configuration change. You can compare the configuration of the build that didn't resolve the parameters with the configuration of the one that didn't by going to the build results page of each build > Artifacts > show hidden artifacts, and comparing the .teamcity/settings/buildSettings.xml files. That should help you identify if there were any differences in the build configuration settings other than the 
Enforce Revisions Synchronization option.
1
Avatar
RJ
Created

Hi Anatoly, thanks for your reply.

  1. I was following TeamCity Docs where it suggested:
    In most of the cases, the finish build trigger should be used with snapshot dependencies, that is the current build configuration where the trigger is defined should have a direct or an indirect snapshot dependency on the build configuration selected in the trigger.
    My main use case is to have A automatically trigger B and I'm fine with this setup. I'm just wondering why triggering B itself will cause it to run twice instead of once. From your reply, it seems like this is the correct behaviour when both snapshot dependency and finish build trigger are used. I may have misunderstood the configuration.
    Would it be logical to have each build configuration in the chain run once every time any build configuration in the chain is triggered?
  2. Thanks for the debugging tips. I will have a look at it later.

 

0
Avatar
Anatoly Cherenkov
Created
As I understand, you start configuration B manually. The doc you refer to implies that you (or VCS Trigger or someone/something else) will start configuration A first, not B. In that case, after a build of A runs, a build of B will also run. However, in most cases, such a scenario can be simplified into the following:

1. B has a snapshot dependency on A.
2. B has a VCS Trigger (assuming you need to trigger the A -> B chain if a new commit comes in), or you run a build of B manually.

In that case, when B is started, it will check if there is an existing suitable build of A. If there is one, a build of B will start right away. If not, a build of A will start first, and then B. Is that what you are trying to achieve?
1
Avatar
RJ
Created

Yes, that's exactly what I'm trying to achieve.

I'm just a bit surprised that B will run for the second time due to the finish build trigger, even though someone has manually started B, which is already a part of the build chain from the beginning.

0
Avatar
Anatoly Cherenkov
Created
I understand your concern now. Which TeamCity version are you on? I would like to look a bit deeper into it. Anyhow, I would not recommend having a Finish Build Trigger in B watching A, if you manually trigger B.
1
Avatar
RJ
Created

Hi, I am on TeamCity Enterprise 2022.04.4 (build 108763).

Thanks for your suggestion.

0
Avatar
Anatoly Cherenkov
Created
After looking deeper into it, it seems I was wrong about the intended behavior. I don't get the second run of B in my test setup. The teamcity-triggers.log has this entry:

[2023-05-03 16:38:51,651]   WARN - RIGGERS.buildDependencyTrigger - Case5044694_BuildB: [] Will not trigger a new build in Case 5044694 / Build B {id=Case5044694_BuildB/bt156} because there is another build chain which already includes #1 {build id=235, buildTypeId=Case5044694_BuildA} and some other build from Case 5044694 / Build B {id=Case5044694_BuildB/bt156}

It means that the Finish Build Trigger logic accounts for the fact that the same build already exists in the same chain, and the trigger doesn't queue another build. You can check the teamcity-triggers.log on the server side and see if you have any relevant entries mentioning buildDependencyTrigger and the ID of configuration B. If it still triggers the extra build, most likely it means that the extra build is not the same as the original build. You can use the Compare Builds feature to compare both builds and see if there are any differences (click on the three dots next to a build history entry and click 'Select for comparison...').
1

Please sign in to leave a comment.