Programmatically waiting for another deployment to finish before deploying the current project

usability
server
known
(Joseph Baggett) #1

Let’s just say I have two projects, both projects stop and start IIS. The problem I am trying to figure out, is how can I call Octopus to look up the deployment status if something is actively deploying? I have tried looking through the Octopus.Client dll, and I don’t see anything getting pulled back that I can use to control the other project from not deploying if the other project is actively deploying.

Any solutions on this?

Joseph

#3

Hi @joseph.baggett

Thanks for getting in touch!

Before I dig into a way to check this programmatically I just wanted to dig in a little deeper about your deployment scenario. By default if you are deploying to the same target (i.e. server) in the same environment we will only allow one deployment to proceed at a time. If this matches what your deployment scenario then there may be nothing to do here as we are safe by default.

You can read a little more about that here, which is the support page on how to override our safety settings.

If you would still like more information or help on checking this via Octopus.Client / API then please let me know.

Regards,
Alex

(Joseph Baggett) #4

I have multiple projects that may be deployed to the same server that are completely separate. There is no chaining desired of any deployments as each code base is different, but they may interfere with each other on starting and stopping of resources shared, which is the reason why I need each deployment to wait on each other.

OctopusBypassDeploymentMutex, setting it to True does not work, as I tested it across different projects and 2 out of the 3 fail due to the different projects stepping on each other.

#5

Hi Joseph,

Sorry that it has taken me a few days to get back to you.

You are correct that setting OctopusBypassDeploymentMutex to TRUE would give you the opposite effect to what you are looking for as that setting removes the concurrency protection that we have in place.

I want to confirm that the default behaviour is also not preventing your deployments from clashing?

If you can let me know I can go digging in our API and see if I can find something useful for you.

Regards,
Alex