Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Variable as Lock Token
-
Is it possible to use the value of a variable as a lock tocken? Based on the grammar it looks like the lock tocken needs to be hardcoded so it is known during execution. If it is possible can someone provide an example? Simply doing something like
with lock = $LockToken { }
gives a processing error when attempting to save the plan.
There were one or more errors processing your script: [Error] Line 2: Expected {
Product: BuildMaster
Version: 5.6.8
-
As you noticed, this is not possible. A lock token is intended to be static.
Can you help us to understand the use case for needing a dynamic lock token?
-
That is unfortunate. I had intended to use locks to emulate server pools in a sense, in order to prevent builds from running on top of each other. I have multiple build servers that can build multiple different applications in parallel. However, each build server can only have one instance of an application's build running at a time. If a new build request comes in for an application but that application is already building on all of the servers the build needs to be queued up. With variable lock tockens I was hoping I could do something like the following to create a global lock tocken based on a combination of the build server to use and the current application being built.
set $BuildServer = ''; call ReturnRandomBuildServer(returnServer => $BuildServer); set $LockTocken = $Eval($BuildServer)_$Eval($ApplicationName); with lock = !$LockTocken { }
-
We are very close to finishing the following operation (it's in test stages right now):
# acquires a server associated with the build-servers role Acquire-Server( Pool: @ServersInRole(build-servers), ServerName => $AcquiredServerName ); for server $AcquiredServerName { Log-Information Acquired server: $ServerName; }
This would eliminate the need for the lock altogether.
While designed for the next minor release, we can release this as a sort of "beta" operation in the next maintenance release (v5.6.9)... which should be end of this week early next.
-
That operation looks exactly like what I am trying to achieve. What is the behavior when all of the servers in the pool have been acquired? Does current execution wait or does an error get thrown?