Skip Packages Already Deployed

The option that currently exists to skip deployment of package if already deployed is incomplete. When you have sub-tasks below that, which would be the normal scenario (right, you are deploying it as as a unit). Those sub-tasks execute, only the purge (optional) and extraction is skipped.

Can we please get the option to SKIP EVERYTHING!???


  • Sprint release, 10 applications within it
  • 3 applications are changed, get added to repository
  • Deployment is executed, all 10 applications have to deploy, even though only 3 are new.

Skip packages that are already installed
Octopus can check whether the same version of an included NuGet package has already been installed on the deployment target and skip further deployment of the package. By default, Octopus will always re-install every included package.

Like I said, this only skips the extraction not the following steps which makes no sense. So it wouldn’t extract the Nuget package but it would then stop the app pools, backup, start, etc… ?

Can we get this in? Please???



Hi Dave,

Thanks for getting in touch. The Octopus project setting Skip packages that are already installed instructs the Tentacle not to to install a fresh copy of a package (potentially a duplicate) when the same one already exists. This simply skips a few of the initial prerequisite steps before the actual deployment process is executed. The deployment process is always executed though.

I think there are three main options to achieve.

  • When deploying a release, select the advanced deployment options and skip the packages that haven’t changed (see the attached screenshot).

  • Use channels (introduced in Octopus 3.2) to create a channel per package as well as a channel for all packages. The project would look something like the following.

    • Step 1: Deploy database schema (channels: Full release; Database)
    • Step 2: Deploy web services (channels: Full release; Web services)
    • Step 3: Deploy web front end (channels: Full release; Web front end)
    • Step 4: …

When creating a release, you could then create it in the “Full release” channel (so all steps will run) or one of the specific channels for just that package.

This could be further customised to group packages per release if desired.

We have a lot of information on channels and our introductory blog post is probably the best starting point.

  • Split up the project into separate projects and deploy the appropriate ones individually as needed.

The first option is the simplest but I think Channels is probably the best option.

Hope this helps.


Let’s say that the package being skipped is a Windows Service that is stopped and then started as part of the deployment process. I would like to skip the Stop and Start Steps as well whenever the package is being skipped. Is this doable? Thanks in advance.

Replying to this a little late, I somehow missed the response to my original post…

I’m familiar with Channels and use it extensively to map back to teams and branches.

But I’m not really seeing how using that is feasible. Just to give you a general idea of how I am setup…

I have approximately 50 applications across 5 teams that operate in CI and CD to development environments. Every time an application is changed in source code, it is built, and then deployed. Each of these teams are different channels. Same applications, just different packages based on semantic versioning.

Each Sprint, teams identify which applications are going to be part of the release, and merge up into the release branch. When we know what the release will contain, I create a new project, and then use a utility that an Octopus member (sorry forgot the credits right now) that allows me to copy project steps from one to another. I copy the application deployment steps for each application that is going to be part of the Sprint into the Release Sprint project.

It’s at that time I start using this Release project. The issue becomes, each time there is a change to ANY application, I have to run the entire project. Sure it deploys the same package version if something didn’t change, but it still goes through the process.

I’m not really seeing how channels would help here. The project is what gets promoted up to the next environments, e.g. staging, production. Separating it by web or db or other would still have the same problem, just smaller.

I implemented UrbanCode at a company, and as part of that did evaluations of CA, HP, Serena, BMC, and all of the ARA tools out there support the ability to simply skip if it is already installed. I think what you are suggesting is to hack around a missing feature…

I would prefer at this point to redeploy than start altering the release structure to try and support the missing feature.

I’d still like to see this added. Seems pretty reasonable and not difficult to check if, it is installed already, don’t execute the sub-tasks, rather than what you are describing (which doesn’t address it anyway).

Hi Dave,

Thanks for the reply. I think you make a good point as the options I described don’t really suit your suggestion. Unfortunately, Octopus doesn’t really support this scenario at moment. I’d recommend visiting our user voice site at and adding a new suggestion or reviewing the two somewhat similar ones below.

We regularly review the suggestions and watch the ones that gain the most community support.



I have a build process that gathers packages for matching versions of components that work together and releases that have steps for each of those packages.

I am planning rollbacks using machine images on cloud and need to know if information on which package version is currently on target machine is stored in tentacle.


Thanks for getting in touch. Tentacles store a deployment journal file (`deploymentjournal.xml) as well as copies of packages etc. The deployment journal is an XML file and it’s easy to understand so I’d recommend using it. For more more information, see our retention policy page as it goes into more depth on this. An example is as follows.

<?xml version="1.0" encoding="utf-8"?>
  <Deployment Id="3bfa50a7-fc62-4841-aad6-3198e1b2b38d" 
    InstalledOn="2016-12-22 04:59:49" 
    WasSuccessful="True" />

Another option would be to retrieve that information from the Octopus API. Octopus primarily works with Environments and Roles but it is possible to determine what releases are deployed to different machines. I can point you to two previous forum questions with example scripts that retrieve this type of information.

Hope this helps.