Referencing other projects during deployments

I have a massive system that I will be deploying in the coming months with approximately 50 points of integration with external systems. My goal is to deploy this entire system and include it’s dependencies downstream. Currently those dependencies are set up as projects of their own and are on a different development pipelines/timelines as the primary system I’m deploying.

My thought was doing either one of two things. I either use something like Octo.exe to deploy the projects or use the rest API to deploy them. I could have a step that says Deploy Dependency A that calls back into Octopus telling it to deploy another project/release number combination and let that go. Either that or we would need to track each dependency manually and at deploy time someone would need to go through each project for each item and deploy it.

The biggest issue I have with the first option and wanted to ask about is if I were to move in this direction how do I know to fail my current deploy if the project for dependency A fails? I’m guessing I could use the API to watch the tasks status to see if it’s successful. Do you all have any suggestions around that?

I would rather not manually track them and moving everything into a single project isn’t viable due to development timelines.


Thanks for getting in touch!

As you’d be aware, Octopus has no built-in concept of dependencies between projects. We generally take the position that if a collection of components needs to be deployed at the same time, they should be in the same project. However, your situation isn’t uncommon.

We find a lot of customers with dependencies between projects use an external tool (often built in house) to orchestrate deployments for multiple projects. Alternatively, they add steps to projects that trigger builds for other projects. A couple of things that might help if you go down this route:

  1. Octo.exe has an argument you can use when you’re deploying called --progress. This will block, and wait until the deployment has completed, so you can check for success or failure before moving on.
  2. There’s a community library step template that will trigger a deployment of another project. This can be handy for deploying dependent projects if needed.

I hope this helps!


The community library step template cannot be imported into version 3.3.12. It comes up with a validation error.

Any ideas how to overcome this?



Thanks for reporting this - we noticed that we had broken some compatibility when we introduced some increased validation between versions. I’m really sorry this has affected you!

While we fix it, the easiest way to resolve would be to remove the following line from the JSON pasted in (it should be at the top - as per the attached screenshot):

"Octopus.Action.Package.NuGetFeedId": "feeds-builtin",

I hope that helps!



Awesome. Great to know that you’re on it.