Is there a non-blocking wait?

Hi,

I have the following deploy process (not sure if I understood everything right as I still try to figure out some relations [e.g. environment <> target]).

The app process is performing the overall choreography of the deploy. When the environment is PlayStore Dev Testing the actual deploy will be handled by thy app-creation process and for all other environments it will be handled by the app-promotion process. From my point of view this “split” is quite handy as I don’t need to place a lot of conditions into one process depending on the environment but just start a sub-process.

I have one deployment target (PlayStore Target) to manage the deploy.

The problem is, that app-promotion is long-running because it’s a rolling deploy taking up around 2 days for a complete roll-out for PlayStore Alpha Testing (1 week for PlayStore Beta Testing and 2 weeks for PlayStore Production). The process themself contains multiple Wait tasks.

Which are simply derived from the pre-existing Wait task to accept an environment variable as wait time.

The main problem that will occur, is that while a deploy is still “waiting” in the app-promotion process, no other deploy can be done in the app-creation process because the target is still in use (even if it’s only waiting).

I tried to add another deploy target (for example PlayStore Creation Target (env. alpha only) and PlayStore Promotion Target (other three envs.) only for the given environments) but this will cause errors in the main process. I also tried to add more targets which are the same as the main target but this caused the process to run multiple times causing other errors. Finally, adding more target just blows up my target “budget” and it’s looking unnecessary to me because the Tentacles are 99% of the time in Wait tasks anyway.

My question is: Is there a non-blocking Wait-Task which allows a tentacle to perform other tasks while waiting?
Are there any problem / mind-traps which I might not notice?

Any help would be welcome :slight_smile:

Hi @Heurazio,

Thank you for contacting Octopus Support.

You have a couple of options here. First is to enable multiple processes on a single tentacle:

Another option to consider would be to break the project up. In your example, you have 3 waits, which would potentially mean 4 projects (assuming all of the waits are extremely long). You could then use Scheduled Triggers and/or Runbooks.

To implement that, you would likely need to either do an API call as a run condition to check if the preceding project was successful. You could probably accomplish the same thing by setting and checking variables, but that could get messy.

The simplest option is to enable the multi-process tentacle and keep everything the way it is.

Let me know if you have any questions or if there is anything else I can help with. :slight_smile:

Regards,
Donny

While it’s now possible to start a process of app-creation while an instance of app-promotion is running it is still stuck with:

Waiting for the script in task ServerTasks-38086 to finish as that script requires that no other Octopus scripts are executing on this target at the same time.

So if I understand this correct, I still need to wait for the PlayStore Alpha Testing to be finished :expressionless: |

Hi @Heurazio,

Thank you for getting back to me.

Did you set the “OctopusBypassDeploymentMutex” variable for all of your projects? If the first project is set to true, but the second project is set to false, the second project will still wait for the first project to finish.

Regards,
Donny

Thanks for your reply.

I have altered all three projects and applied:

to them. Unfortunately, it’s still stuck as shown in my previous post. For safety, I also run multiple deploys just to make sure it’s not because of old process versions.

Hi @Heurazio,

Thank you for getting back to me.

Can you confirm that it is the “wait” step that is running when this block is occurring?

I’m going to attempt to reproduce this on my end to see if there is something going on that we aren’t considering.

I look forward to your response and appreciate your patience while we get this worked out.

Regards,
Donny

Hi @donny.bell

as long as the app-promotion process is running, the app-creation is “blocked” by the before mentioned reason:

Waiting for the script in task ServerTasks-38086 to finish as that script requires that no other Octopus scripts are executing on this target at the same time.

The wait is not “breaking” the block or releasing the tentacle to perform the other process. The Wait I use is derived from the pre-defined wait and looks as followed:

$Wait = [int]$Seconds
for ($CountDown = $Wait; $CountDown -ge 0; $CountDown--){
Write-Verbose "$CountDown seconds remaining"
Start-Sleep 1
}

I just altered it so that I can pass a variable instead of a fixed period (that’s why the cast to int is there).

Hi @Heurazio,

Thank you for the quick response.

Apologies in advance for the basic question. Did you by chance create new releases for each project after setting the mutex variable? If not, I would definitely do that then try again. Previously deployed releases, when re-run, won’t introduce a new variable added to the project until a new release is made.

Let me know what you think.

Regards,
Donny

Hi @donny.bell,

yes, I created new releases (two, to be precise so that they will run at “the same” time) after introducing the mutex variable.

Hi @Heurazio,

Thank you for getting back to me.

Unfortunately, I was unable to replicate your issue in my test environment as I was able to deploy simultaneously both between releases in the same project and with separate projects.

As I mentioned previously, it may be worth considering breaking up the project into sections and scheduling the releases (if you are just waiting on a start-sleep -s XX to finish).

Let me know if you have any more questions.

Regards,
Donny