Automatic release creation to multiple channels
It would be helpful to be able to specify multiple channels for automatic release creation. The way we are using channels, no package is eligible for more than 1 channel. Without this, the development team now needs to remember that for some channels they don't need to go to octopus to create the release and for others they do.

-
Darren Ball commented
Just piling on at this point, but we would also benefit tremendously from this feature. As a side note, being able to go to the channel then see variables for that channel only would be helpful as well. Our variables section for projects supporting multiple channels has grown a little out of control because of all the scoping.
-
Michael W commented
We need this as well, please make this a priority.
-
Andrew Finger commented
The build system and deployment system need to be able to match the package name using ARC, but with having to kick off releases from the build side (TFS, in my case), the build system now also needs to know the deployment project name. Utilizing channels as they are feels like a step backwards in the decoupling process between build and deployment.
-
Hi All,
My general recommendation is to use one of the CI extensions for TeamCity, TFS, VSTS or Jenkins etc, or `octo.exe create-release` (which is what these all call under the hood). These tools will automatically detect the best channel to use when creating a release which means you shouldn't need to leak channel details into your CI tooling.
-
Jorik Uiterwijk commented
This is a big miss for us... we'll use the TFS step instead of Octopus triggers.. hop that will help. Too bad
-
Neil Hosey commented
Pretty disappointed this isnt available, and considering this is a year ol,d Im guessing it never will be.
My scenario is:
I use gitflow. I auto release and deploy to Development env from the develop branch, this is in its own lifecycle.
We have a second lifecycle which I would like it to auto deploy to QA and allow promotion to higher envs, from a release branch when it is created. -
William commented
I am running into this now. Would be great if you could add....
-
Chris Trotter commented
I really wanted to separate build from deploy tasks, so TeamCity does our builds and uploads to the Octopus library - package-1.0.x is for staging/prod, package-0.0.x is for testdrive auto-deployment.
I set a rule that says 'any new package-0.0.x, create release, and deploy on new release' - only for the testdrive-autodeploy channel.
Then we added a number of other package sources to the project process - all with matching version schema (and channel version rules to match).
Unfortunately, the only package in the release that is on the correct 0.0.x version is the one in the ARC trigger. So this means we need to continue our old practice of using TeamCity to trigger deployments.
Not world ending, but all we're missing from Octopus is the ability to specify 'from the list of packages required in my process, use only (version rule), and trigger when a new package-0.0.x shows up.
-
Ryan Gribble commented
I've just submitted a PR for Octo.exe that does this, at least for those creating releases from TeamCity or command line
-
Andrew Krock commented
+1 this would be very helpful
-
Thomas Kragh commented
+1 This was a showstopper in our project as well.
-
Dave Hahn commented
OMG, why is this not in here? I have gone through and setup projects and channels to support 5 different teams / branches and I can only select ONE channel for automated deployment? Why in the world would this not be part of this? This has gone from a great feature to useless in a matter of minutes!!!!
-
Pauli Østerø commented
Yeah, i really need this as well. We have a setup with multiple feature-branches where we always use "Automatic Release Creation" on all of them, and i was really looking forward to start using Channels. Until i ran head-on into this issue as well. Our versioning-rules are very strict, so there would never be a case where a package would match multiple channels - we have a simple 1:1 tag:channel naming convention.