So we have a process that deploys multiple packages. When you set up automatic release creation (Triggers), you pick which step to trigger off of. So I picked the first one. The channel I am using has version limitations in place (the auto-deploy channel uses 0.0.x and the ‘main’ deploy channel uses 1.0.x).
I want all new 0.0.x packages to trigger an automatic release and deploy - this is working.
However, when it automatically creates the release, the package version for the step I picked is correct, but all the subsequent packages use their latest package by version number (vs. by date).
Is there any way around this? The only solution I can think of is to have two artifacts in the Octopus library - Test-Artifact-0.0.1 and Artifact-1.0.1, or perhaps to put everything under one parent step, and use that as my version picker.
I’ve attached some relevant screenshots. Maybe I’m doing it wrong?
Thanks!
-Chris
Hi Chris,
Thanks for reaching out! Unfortunately automatic release creation wasn’t designed to define the package rules. It’s main purpose is to handle when only the package is available on the build without being able to define release parameters. That was mainly due to how older Team Foundation Server versions worked.
You can’t use ARC for multiple channels. Though we have a UserVoice suggestion to implement this functionality, so go give it a vote!
What are you using to build your package? We recommend using Octo.exe as a great option as you can determine the packages you want to use for each release.
Kind regards,
Kenny
We’re using TeamCity for build tasks. I will rethink how I’m doing things - glad to have this input - thank you!
Actually - curious if there are any patterns I should be following, but clearly am not based on running into this scenario.
Some questions, taken with a grain of ‘Octopus-team-bias’ salt:
What SHOULD the TeamCity run be doing?
What SHOULD Octopus itself be doing?
Hi Chris,
When you are building the project in TeamCity you have a lot more information than Octopus when it receives a package. For ARC we have a package, no reference to release, associated packages nor project. It all has to be inferred. We can make assumptions like this project as it has that package ID, and create a release based off the package version, but we then have to make a bunch of assumptions such as including the other packages versions, and if pre-release tags are used, should we assume it matches for all packages or just for the lead trigger packages and use the stable version of others. The design was the latter. When channels came along this was not changed as what if there were conflicting rules and what if we couldn’t find all the same packages - behaviour was not easily determined. So thus the UserVoice we linked. It will be a slightly larger feature than 1 or 2 settings.
So based off this, and the ability from TeamCity to include our plugin, you also have much more context explicitly than we have by implication. You know the project, the package versions and can defined those with the create-release function for each package. You have much much more context and available information. So we suggest you define it while building and push it through to Octopus from TC.
There is debate where it all should fit in the CI and CD process. assuming or expecting Octopus to take over once a package is pushed would be best practice, it is just we can’t get enough information from the package alone for a complex set of requirements. We agree, but the feature at present isn’t complex enough.
Please let me know if I can help or give guidance on what you need to define to get the process working.
Vanessa
That’s some great information, thanks!
So I guess now it really comes down to how we’ll identify packages based on autodeploy or release.
And yes, this is a complicated issue to deal with - my comment about a tiny feature missing would solve my problem but probably not the problems of many others. 
It seem that the reality of software development right now is that patterns cannot easily be applied because people are inflexible/sins of the father…? “that works for you, but won’t work for us because of tech debt/this is how we’ve always done it/that’s too hard” So when the opportunity arises to start from scratch w. new process - would be super handy to “just apply the pattern” and stop messing about with plumbing, so to speak.
Anyways…haha. Thanks again, I’ll take another stab at it this week.
Hi Chris,
TeamCity specifically has extra arguments in the plugin for create-release where you can pass the package version for each package, and this can be determined from variables.
A bit about what you can include can be found here: http://docs.octopus.com/display/OD/Creating+releases
Vanessa
