Hi, we’re currently using 2.6.5.1010 but looking to upgrade in the next week to V3.
We are using Octopus to deploy a test website and then automatically run Selenium UI tests using MSTest. These tests take up to an hour to run (by design).
If TFS runs another build while existing tests are running and tries to create a new release, Octopus queues that release waiting for our existing deployment (UI test run) to finish. The problem is, in this situation, the new release normally times out and does not get deployed once the current tests finish.
I notice that there is a “deploymenttimeout” parameter that can be passed to Octo.exe to override this timeout value, but we are using the REST API to create releases. Is there any other way that we can override this timeout when creating releases to make it a much longer period?
And if not in 2.6.5 - is there any change to this in V3?
Thanks for reaching out! The --DeploymentTimeout is a feature that only exists in Octo.exe (actually in the [Octopus.client] (https://www.nuget.org/packages/Octopus.Client/)), which basically uses the REST API to check if the deployment has finished or not before it continues. On the REST API call itself there is no way to set the timeout neither in 2.6 or 3.0
Changing your deployment trigger step to use Octo.exe instead of the raw REST API might be the best in this case.
Thanks for coming back to me. Does that mean that Octo.exe would actually stay running for 10+ minutes if a deployment is still in progress on the server? Does it keep checking the REST API to see if the deployment has finished?
If I’ve understood you correctly and in this case Octo.exe doesn’t return immediately, I’m wondering if this would keep our build “running” in TFS for 10-20 minutes while Octo.exe waits to be able to create a release (since TFS is calling Octo and waiting for the process to exit)?
That’s correct, Octo.exe will poll the API every few seconds to see if the deployment has finished (only if you pass --waitfordeployment or --progress). That timeout value tells Octo.exe how long to sit in that loop for.
If you use Octo.exe to queue the deployment, without either of those parameters, it will start the deployment and return right away, letting your TFS build complete while Octopus runs the deployment.
Thanks for clarifying. In that case I think we can update our post build script to kick of Octo.exe as a separate process and not wait for it to complete. That way the TFS build will finish and Octo will just run until it can successfully create the deployment.
Is there an upper limit on how high we can set the --waitfordeployment value to? Our UI test deployments take 1.5 hrs currently!
I think we misunderstood the original question. Currently, Octopus will only deploy a single project/environment combination at once, and other deployments get queued. After 20 minutes, a queued task that doesn’t start will cancel, and we have no way to override this.
Using the flags in Octo.exe actually does nothing to control this - Octo.exe only submits the deployment once, and then waits for it to run. If it times out, Octo.exe will return - it won’t keep requeuing the job.
At the moment we just don’t have a way to handle this; you’d need to use the API to keep checking the deployment state and if it times out, re-deploy it.
Thanks, having checked the docs I also realised that we have “crossed wires” here! The 20 minute timeout is exactly what I was referring to.
I can see how to put together a simple Powershell script to get round this, so thanks for clarifying - I’ll come up with a workaround for now.
It would be hugely useful to be able to override this global timeout at a system level at least (if not at project level) - perhaps like the deployment Mutex variable?
Thanks for your time and keep up the good work
Chris.
Hi I wondered if the change in the latest update has a bearing on my issue described above? Ie. has the timeout that was causing me an issue now been removed?
1958 - Remove task queue timeout for all but scheduled tasks
That’s right! We’ve removed the timeout completely in that release. They will only apply if you schedule a deployment for a specific time (say 7pm next Monday) and the task doesn’t run around that time. For “deploy ASAP” deployments they will never time out.
