Situation:
We have a list configurations to build the different application of our product line, and some of those applications have inter-dependencies. Let’s say we have App1, App2, then App3 references some DLLs that are built by App1, and so on…
For those applications that build DLLs that are referenced elsewhere, we have setup a server share location where our configurations output the needed files during our builds, by using a file copy operation in a stage.
\ServerShare\Dependencies\App1Output*.dll
\ServerShare\Dependencies\App3Output*.dll
…and so on.
Then we have the configurations that need the DLLs from other projects fetch them from that server share location by using a FileServer repository.
When we build our configurations one at a time, it works fine. Whenever new DLLs are available in one of the file share’s subfolder locations, the repository is updated at the start of the a build that needs those files. We can build all the projects after one another, or we can build a single project if we want which is going to use the latest DLL references that are available for it.
However, we run into a problem when we try to build all the projects by queuing them. If we want to perform all of our builds unattended, we would press start on all our configurations, so that App1 starts while all others are queued, then when App1 finishes App2 starts by itself, then App3 and so on, and let the whole thing run…
When a build is queued, it appears that it fetches its repository changes at the moment where the build is put in the queue, and the repository is not refreshed once the build comes out of the queue and the first stage starts. So while App2 and App3 are in the queue, App1 creates the reference DLLs and uploads them to the server share. Then App1 finishes and Continua moves on to building App2. After App2 is done, App3 comes out of the queue and starts synchronizing its workspaces. However, the FileServer repository content remains as it was before App1 was built, so App3 is not using the latest reference DLLs that were generated while it was waiting in queue.
My question is then:
Is there a method to update a repository while a configuration is waiting in queue, or a manual step that I can add to a stage that would do this? Thank you
Hi Lesergeur,
It would be a major change to move the repository checking and updating to take place after an agent has been allocated for a stage. Also, expressions used in build conditions and agents requirements (which are checked before allocating an agent), may be dependant on repository changesets - so this would be a breaking change for many.
Perhaps what you are really looking for is a “dependencies” feature where each configuration depends on artifacts from one or more other configurations. This feature would check dependant configurations and require them to be built or at a certain state before starting. This is a feature that we have had on our to-do list for sometime. It’s partially designed but we have yet to schedule this work as we need to complete some other major features that we are currently working on first.
If your configurations are only dependant on one other build configuration, as in your scenario, then you can achieve a similar outcome using Build Completed triggers . These can be used to trigger a build when another build has completed.
You could, for example, add build triggers to each of the configurations for App2 and App3 which cause them to be built when App1 has completed successfully. To build App2 and App3, run a build for App1. You could also put flow control logic in the configuration for App1 so that the build only does anything if there are changes but still triggers builds for App2 and App3. You could also use variables with trigger conditions to control whether App2 or App3 or both are built when you queue a build for App1.