How should the deploymentId be tracked and made available for all builds in a build chain?

[gesellix]

-> https://youtrack.jetbrains.com/issue/TW-68592

[gesellix]

The answer at https://youtrack.jetbrains.com/issue/TW-68592#focus=Comments-27-4510012.0-0 helped passing the deploymentId across builds of a build chain using the BuildStartContextProcessor and a shared parameter:

Anton Zamolotskikh commented 2020-11-12T17:32:03 @Tobias Gesellchen ok. First of all build chains do not exist as a standalone identifiable entity and doesn't have any persistent storage associated with it. So it seems you will have to rely on knowing (or finding out) which build of the chain has generated the deployment id.

So far I see a number of possible approaches.

• If the id is something that your plugin generates and the build configuration. that does it, is known, you can use the build Id of the build that is supposed to generate as such deployment id;

• Alternatively you can use build parameters. If you implement BuildStartContextProcessor interface and then use context.getBuild() to check if the build is relevant and then context.addSharedParameter(name, value) in its updateParameters method, you can create a build parameter. Then it can be accessed from the event handlers for other builds via Build::getParameterProvider and then getAll;

Two more approaches involve implementing your own storage for this information. You don't have to implement the persistent storage all the way though.

• One way is to implement an in-memory storage backed up by some kind of a cache implementation. Other TeamCity plugins use EHCache library for example. I would not advise it though as keeping the value of the id between builds of a chain id is critical and caches can be cleaned;

• Another way is to use custom data storage, which can be obtained for a build configuration using SBuildType::getCustomDataStorage(). The word of caution though: you will have to clean that storage, as it is associated with a build configuration, not with a build and over the time there will be quite a lot of old ids in that storage otherwise.

[gesellix]

Re-opening due to issues when running under TC 2020.2. See the linked ticket.