I’m trying to set up a system with this configuration:
Every deploy includes 2 different packages to deploy, one package with webapp and a second one with a WindowsService
2 different channels:
- Channel A is using default lifecycle and has a version rule to select packages tagged with ‘RC’ (1.0.5-RC)
- Channel B is using a different lifecycle and has a version rule to select packages tagged with ‘TEST’ (1.0.2-TEST)
When we try to create the release manually for each different channel, it is only displaying the packages with the specified TAG in the rules.
But when we try to do it with ARC option is ignoring the channel rules at all, and only applying it for the package selected to trigger the ARC.
If we select webappPackage to trigger ARC is creating a release with:
- webapp 1.0.5-TEST
- service 1.0.1 (last package without tags)
If we select servicePackage to trigger ARC is creating a release with:
- webapp 1.0.1 (last package without tags)
- service 1.0.5-TEST
Based on the text under the channel version rules section, we think it is not following the expected behaviour:
“Version rules are used to filter packages on the create-release page and when automatically creating releases as a result of a package being pushed.” Is correct with the first part but not on the “automatically creating release” part
And also on the process page when you activate ARC says:
"For the release to be created, the pushed NuGet package must satisfy the selected channel’s versioning rules (if any)"
And is only applied to one of the package for the channel, not all of them
Is there any option to make this working for both packages and not just one?
Is there any plan to include this feature/fix in future updates?
I am also affected by this bug.
Hopefully this will be fixed soon.
Thanks for a great product
Hi Alvaro and Thomas,
Thanks for getting in touch! Unfortunately this is not a bug but by design. When you use ARC and pre-release tags on your package versions, if you have multiple packages we cannot make the assumption of which package you would want to use a pre-release package for. So only the triggering package will ever be a pre-release tagged package. Currently channels and channel versions do not assist at all.
We do have a UserVoice suggestion for ARC to be assigned per channel and use that channels rules for package selection: http://octopusdeploy.uservoice.com/forums/170787-general/suggestions/10776963-automatic-release-creation-to-multiple-channels
Add your votes!
The user voice you add to your message is related to use ARC with multiple channels.
I’m intended to use it just with one channel. But this channel has multiple packages.
So it is not apply to my situation. I will try to find a correct uservoice request or create a new one.
And related to your answer, I not agree with your explanation.
An ARC is triggered with a package and also with a channel related. If this channel has version rules specified for all the packages, you just need to follow this rules when you try to select the packages. Same way is happening when I try to create the release manually, and the correct version is preselected for all the packages and I just need to click create.
Why not follow the same rule during the auto release creation?
And if it is not a bug, and is the desire functionality, why the text on the version rules says explicitly “Version rules are used to filter packages on the create-release page and when automatically creating releases as a result of a package being pushed” and then is not use to filter all the packages when automatically creating releases?
Thanks for your time.
If any one else arrives to this post. here you can find the uservoice request related to this bug (yes I still think it is a bug).
I did link the correct suggestion, and it will solve you problem. We do not apply ARC to channels nor follow their rules apart from the pushed package. Having ARC defined at a channel level (multiple or not) will get you the behavior you want.
There is a fundamental difference between using the UI to create a release, and creating a release based on pushing a package. In the UI we already know the project, and you define the channel. When you push a package into the internal repo all we have is a package. We have to match it to the correct project, then we would have to match the channel. Then what if we match more than 1, we can’t have more than 1 release named the same, how would we chose which channel, or what to call the release or a myriad of other concerns. We cannot trust that each channel will be exactly explicit and not overlap! There are cases when they shouldn’t have to be different. It was too complicated a problem to solve with channels so we decided to leave it as it was currently working and see what the community needs would be to then try to come up with a solution that everyone would like.
I do understand what your saying, and you can disagree, but it doesn’t change the why or how it was implemented, and channels never say they will do anything with regards to ARC you still set it up via the project and we never changed how it worked. Voting on the ticket I linked will get you what you want much faster than creating an overly unique slightly different suggestion.
I can understand that there are some reasons (agreed or not) to have this implementation.
But what you cannot say, and I’m completely not agreed is that a suggestion asking to have a multiple channels on the automatic release creation it is slightly different to a suggestion related to have 1 automatic release creation applying channel rules to all the package included on that process.