Select a channel using OctoPack?

We publish packages to Octopus using OctoPack.

Now we need to start using Channels for the first time.

Does OctoPack support selecting a channel when publishing the package?

Hi Michael,

Octopack only takes care of the packaging + pushing, while selecting a Channel is an action tied to the Release Creation. So the short answer is that Octopack cannot help you select a channel.

The recommended approach would be to add a step to your build process that calls Octo.exe and create the release for the channel you want that way. If you have ARC enabled to automatically create your release, you’ll need to turn it off for this approach or else you’ll end up with 2 releases being created.

Best regards,
Dalmiro

Thanks. I looked at that, but the API looks better. Actually found a nice PS script on GitHub that uses the API to create a release.

Hi Michael,

While its true that you can do the same thing as Octo.exe using an API script, in this case I’m gonna advice you to avoid the API route and go with the command line tool instead if possible.

We have a very extensive list of unit/integration tests to make sure that Octo.exe works as expected on each release. If it was me, I’d rather rely on a tool that’s tested and supported by an entire team, rather than relying on a script I wrote myself/found in github that might not consider all the possible scenarios.

Dalmiro

Thanks for the suggestion, however we are very experienced with Powershell (…very) and feel most comfortable with that. Having said that, are you suggesting that the API is not as well maintained as Octo.exe?

Hi Michael,

No tests in our pipeline are more extensive that the ones for the API. The API is the base of everything. Octo.exe is merely a smart wrapper that exposes the API’s functionalities through its commands.

The point I’m trying to make is that the API script you’ll be writing is going to have to consider quite a few scenarios and handle them accordingly. The team that created that API has a bit of an upper hand when it comes to knowing all the nooks and crannies of the entire process.

I definitely trust your Powershell skills! But I believe that, in the long run, trusting the CLI tool that is maintained by our team is going to pay off more. A few more points to build my case:

  • Octo.exe is in nuget, so adding it to your pipeline should be very easy https://www.nuget.org/packages/Octopustools . If you are using TeamCity or VSTS/TFS2017 its even easier becasue we have plugins for those build servers

  • Octo.exe has a lot more features than a single-featured script. As we keep adding features to Octopus, this CLI tools will follow it by adding support through its commands.

  • Adding a call to Octo.exe its as easy as It’ll be adding the call to the script you want to write.

Dalmiro

I’m open to being convinced, but when I tried to access Octo.exe from Powershell it seemed like there were a lot of layers that were needed to get it to work. Accessing the API was quite a short and easy path. It was just “there”.

As long as you are happy with your approach, so am I :slight_smile: