Share highest revision number of build chain

Hi Ben,

Under this circumstances, the usual approach is to introduce a new build configuration at the start of the build chain that determines the build number. Then all other builds determine their build number as a reference to the parameter of that build as "dep.<build_id>.build.number".

Would this be a solution for you?

HI there

Would that mean I have to check out the entire repository as part of that build configuration? That's something I'm already doing in the final configuration as a temporary solution to the problem, and it adds a few minutes onto our build time which we would like to avoid.

Ben 

Hi Ben,

Not necessarily. If you add the VCS Roots, you can select "Do not checkout automatically" on the VCS Root settings of the build configuration. That will prevent teamcity from downloading all the content. Then you can run your script checking the external repositories for the revision number you are looking for and set it as the build number.

Ok, that sounds like it could be my solution. One more question:

all other builds determine their build number as a reference to the parameter of that build as "dep.<build_id>.build.number".

We create new versions of our product by copying the root project for the whole build chain. When we make this copy, will references to dep.<build_id>.build.number be altered correctly, or will they still refer to the config in the original root project?

Ben

Hi Ben,

currently those references will *not* be updated. There are two decent options: Create a project-wide parameter and use it as the build number, instead of dependency reference. Then the build configuration that sets the build number sets the value of this parameter via the REST API (just setting the parameter in the build will not work, as dependencies will pick up the project-wide value). The other option is to simply replace the references, which should probably be an easy task. If your build configurations are numerous, you can easily run some text replacing tool through the XML files stored in TeamCity's data directory.

I've created the issue https://youtrack.jetbrains.com/issue/TW-50592 to upgrade the references in dependency parameters when copying a project. Feel free to watch, vote and add comments if you are interested on it.

It actually seems to be correctly updating the reference on copy for me. However; although this approach does work, it does seem to force all of the build configurations to re-build each time there is a change anywhere in the repository, regardless of whether the specific config is checking that directory out or not. Is there a way of overcoming this?

Hi Ben,

interestingly that approach should work by design, but I did a test to ensure it before mentioning it and it failed to me (repeatedly), that's why i created the issue. When new builds are triggered, could you check what is triggering them? Could you also check whether the triggers are appropriately set?

At present, I am triggering them manually. We also have triggers on the parent configuration that run nightly.  As far as I can tell they are appropriately set.

Hi Ben,

I'm a bit confused. You say that it seems to "force all of the build configurations to re-build each time there is a change anywhere in the repository", but then that you trigger them manually. What is going on? Is there no VCS Trigger through the builds but they still trigger everytime?

What I mean is something like this:

• Config A has a snapshot dependency on config B and config C
• Config B checks out 'repository/foo'
• Config C checks out 'repository/bar'

If I now make a change to 'repository/foo' and manually trigger Config A, Config B rebuilds, but Config C has no changes, so I am able to use the most recent 'suitable build'.

If B and C have a dependency on Config D which generates the build number by using the above strategy (setting the VCS root as 'repository', but selecting 'Do not checkout automatically'), triggering Config A in the above scenario now results in BOTH B and C rebuilding, even though there has only been a change in 'repository/foo'.

Ah, got it. The issue with adding D is that it's never suitable, it has to re-run always. As you can see here: https://confluence.jetbrains.com/display/TCD10/Snapshot+Dependencies, that invalidates it as a suitable build and will force a re-run.

I see.

I guess that means that there isn't an appropriate solution to my problem (shared revision number) that will allow unchanged dependencies to be considered 'suitable'?

Hi Ben,

I'm afraid that's the case, but it would be expected that the dependencies also reuse the build number, which would mean they do actually need to be updated (and thus the build needs to run). If they don't share the build number and their build number is independent, you can set the build number in a later step, instead of configuring
A -> B
A -> C
B -> D
C -> D

You should be able to simply do
A -> D
D -> B
D -> C

The end result would be that B and C would only be rebuilt when really needed, while D would upgrade the build number for A every time.

Reading through this thread and I have *exactly* the same issue, and solved it the way Denis describes. It's good enough for me because A is a 'package' step (runs 'dotnet publish'), which sets the version numbers on the zipped up artifacts it produces, whereas B and C are blind build steps.

I have another dependency A -> E, in the path repository/baz. This one has to know about the version number, so it has to be patched before you build it. I think perhaps the only solution is to build it again (without cleaning first) in the package step, using an artifact dep. A reverse.dep.XXX from A backwards to E (with XXX incrementing) would trigger E every time, so that's not an option. I think you can probably get away with what I do for most incarnations of this issue. It's true that the build number won't be replicated across all your configurations, but at least you get consistent numbers in your output/releases/deployments without re-running everything.

(A good trick I've found for anyone just tuning in is that you can pick up a build.number from a file in your repository by running a script that greps it and prints a ##teamcity directive. Then descendants can pick it up from dep.ParseVersion.build.number. See more here: https://octopus.com/blog/teamcity-version-numbers-based-on-branches )