I screwed up my buildserer and upgraded recently and have started over from scratch. However I now have a serious problem.
I have several configurations, and when one starts, I want it run until it finishes with a success or failure. I don’t want another configuration to start, because each configuration uses a common directory for deployment.
What I’ve noticed happening is when config A runs a stage, and config B is awaiting a license, when a stage finishes on config A (but the script hasn’t finished) config B starts and then config A waits.
Is there a way to allow only one configuration to run at a time and let the others queue up?
Hi Mike,
You can use shared resources to restrict the number of builds from one configuration (or multiple configurations) that run concurrently. For your scenario, you can create a server shared resource with type Single and set each configuration to require a lock on this shared resource in the configuration conditions. Builds will hold on to this lock for the duration of the build. Other builds will wait in the queue for this lock to be released.
I’ll keep that in mind for the future. What I did was get rid of all of my stages. Kind of a hack, but I’ve noticed that my build times have decreased dramatically.
Hi Mike,
This will not completely prevent concurrency issues with your deployment folder - if the build A starts before the build B, but build A takes longer to run to the deployment action than build B, then build B may access the common deployment directory before build A.
We recommend using a separate deployment folder for each build by specified a unique value in the folder name e.g. $Build.BuildNumber$ or $Build.Version$ or using shared resource locks to prevent builds or stages accessing a common folder from running concurrently.