Octopus tasks showing as Deprecated in Azure Dev Ops pipelines

Recently (yesterday?) the Octopus tasks we use in our AzDO pipelines have been marked as Deprecated and Warnings are issued when the pipelines are run. The 2 tasks we use are Package Application for Octopus (task v4.) and Create Octopus Release (task v 4.). Are there new releases of these tasks we should be using or different tasks?

The Create Octopus Release task has a 5.* version available, but if I select that, the pipeline bombs out right away with an error about “No agent found in pool which satisfies the specified demands”. I’m not sure how to handle that.


Hey @cstimac,

Thanks for reaching out and for all of the information.

Sorry to hear you hit this, v5 seems to be causing some troubles.

You can continue to use v4 for now if they’re working for you, but I would love to get to the bottom of the error that you’re getting in Create Release. As part of your ADO pipeline, do you use the Install Octopus CLI step or are you relying on the local octo that’s preinstalled? I’m also wondering if there might be a .NET compatibility issue here. Which version of .NET is your agent currently using?

Looking forward to hearing back.


Hey Jeremy - Thanks for the quick reply!

I’ll do my best to provide the info you are looking for.

We have an instance of Octopus running on one of our servers (v2021.1 build 7665) and use a service connection in AzDO to connect.

The pipeline that has the Package Application for Octo step is for a React SPA, so .net is not involved. All of our .net pipelines use command switches in the ms build step to create the nupkgs and these pipelines only use the Create Release task. The majority of our .net projects use the .NET Core 6.x sdk task. We also have a couple of projects that are on .net 4.7.2 - but there is nothing in those pipelines that specifies any kind of .net version dependency.

Hope that helps, please let me know if you need more information.

Thank you!
Chris Stimac

Hey Chris,

You’re very welcome!

I did some digging and wasn’t able to get to the root of it myself, so I’m going to reach out to the team who manages the plugin and see if they can give us some insight on why v5 might be getting blocked here. They’re based in Australia so I’ll update you as soon as I hear back.

Please feel free to reach out in the meantime.


Hi Chris,

Thank you for your patience. I’m jumping in for Jeremy as he’s now offline as part of our US-based team to pass along the info from the team.

This comes down to the fact that V5 tasks do not embed the Octo CLI, where V4 tasks did. Meaning V5 tasks require the Octo CLI to be pre-installed. To do this, you can either add the Octopus CLI Installer task as the first task in your pipeline steps, as shown below.

Or if you’re on-prem and have no internet access, you can install the CLI on your agents and ensure it’s added to the PATH.

Lastly, there’s no replacement for the Package Application for Octopus (task v4.) The following issue discusses this in more detail.

I hope that helps, and our apologies for the inconvenience and confusion this change has caused you. Let us know if you have any further questions or concerns at all.

Best regards,


Kenny –

Thanks for the below, I finally got some time today to try out the first bit, but have hit upon a new error with the Create Release task. I am testing with one of our .NET core (6.x) pipelines. I added the Octopus CLI Installer as the first task and have it using v8.0.0. I then set the Create Octopus Release task to version 5.*.

The Octopus CLI Installer task appears to run without error:

Starting: Use Octopus CLI tool version 8.0





Hi @cstimac,

Thanks for following up! Would you be willing to send through a build log that includes the new error with the Create Release task? That should hopefully give us enough info regarding the error itself and full context around it to figure out what’s going on.

You can upload it here and mark this thread as private, or email it to support@octopus.com and I can pick it up from there. :slight_smile:

Best regards,


Build log sent to support@octopus.com

Hi @cstimac

I’ve taken a look at the ADO agent logs you sent over in our support emails. Thank you for that!

I can see your “Create Octopus Release” step takes all of 0.02 seconds to fail, so I don’t know if it is even hitting the server. I have a few questions for you if you don’t mind answering them below.

  1. Do you have any version rules on your default channel for your project?
  2. Do you have any versions rules overall for your project?
  3. Has anything with the Octopus connection in ADO to your server changed (i.e. API key, URL, etc.)?
  4. Is there any errors in your server logs for your Octopus Server that happen when you run your pipeline? If so, can you send this to us in the support ticket you opened, please?

I also want to rule out any Octopus CLI versioning problems. Could you please change the version on your Octopus CLI to the latest using an asterisk (*) in the version field? An example of this is below.


That would be great if you could get back to us on the above questions and then try the CLI latest version! Hopefully, we can slim down where the issue may lie once we get this information.

Kind Regards,

Hi Sean –

Ha! Well, it appears that setting the Octopus CLI version to “*” did the trick. Pipeline ran w/o error and successfully deployed the package. Cool. Thank you!

Please leave this issue open for now as it was a 2-parter, and I have yet to try the suggestion for the other part (replacing the Package Application for Octopus task).

Thanks again,







Hey @cstimac,

I’m glad to hear Sean was able to get you in a good state again.

Now that we have that all settled, the news on the pack step is:

  • Octo Pack - This task is supported, but it no longer actively maintained. It is recommended to migrate to the built-in 'Archive Files’) task. Alternatively, if NuGet package metadata is required, consider using the ‘NuGet’ task or the ‘dotnet pack’ task.

Please let me know what you think or if you have any questions or concerns.


We are trying to avoid having to change all our builds to include a new task to install the Octopus CLI. If we do add a task to install the Octopus CLI our builds are working. We tried installing the Octopus CLI on the build server and adding it to the path. In our case we dropped the CLI in a C:\Octopus folder. The directions on Marketplace did not specify if the PATH environment variable needs the trailing slash or not. We tried setting the system PATH both ways (with slash and without) and we still are getting agent issue…

No agent found in pool Default which satisfies the specified demands:
Agent.Version -gtVersion 2.144.0

Even though our build agent capabilities are showing:
Agent.Version 2.202.0
Path redacted content;C:\Octopus;redacted content

Are there some additional steps we need to take so that the build server can recognize that the Octopus CLI installed?

Good afternoon @carters.matt,

Thankyou for letting us know about the agent issue you are now experiencing. I am just jumping in here for Jeremy and Sean as I dealt with a customer the other day who had this issue, though his only required octo (for the Octopus CLI);

The fix for this was to add a ‘user defined’ capability to your worker:

Microsoft has some documentation on self-hosted workers and user capabilities if you have yet to see it which explains how you set up a user capability for a worker.

From your error, it looks like you may be missing some more capabilities such as DotNetFramework and npm?

I hope that helps but let me know if you need anything else and we will investigate further for you,

Kind Regards,

Clare Martin

Afternoon @carters.matt,

Sorry to SPAM this thread but I have just found this GitHub documentation we have produced surrounding the changes for ADO version 5 and what needs to be done.

It mentions installing .net on the agent and also about the user capability.

I hope this adds some insight for you and helps you build your pipeline.

Kind Regards,

Clare Martin

Thank you for the replies. Adding the user-defined capabilities fixed our issue for Octopus CLI.

1 Like

For anyone else experiencing this issue we now have more detail in our documentation on how to install Octo as a user-defined capability which is a lot easier to follow than any of the previous links I have posted already.

Kind Regards,

Clare Martin

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.