I am encountering an issue whereby Octopus finds multiple viable release plans when creating a release. The Octopus process for the project contains multiple steps which involve upgrading kubernetes helm charts for each package in the release. We are conditionally running two of these steps for certain channels only. We are using version rules for each channel.
When a release is created for one of the packages that we only deploy on a certain channel then it appears that Octopus does not use the version rules to determine the correct channel. Instead it will either go to the default channel (if set) or it will fail.
I’m not sure if this is a problem with how we are using Octopus or if it is an Octopus limitation. Could someone please help? I am happy to provide more details or a log if required.
We have a single Octopus deploy project configured as follows
Process
Deploy Package 1 (existing)
Deploy Package 2 (new)
Conditional to only red channel
Deploy Package 3 (existing)
Channels
Black
Version rule for package 1 and package 3 of [1.0.0, 1.1.0) - any build which generates a version 1.0.0.x package should create a release in this channel
Red
Version rule for packages 1, 2, 3 of [1.1.0, 1.2.0) - any build which generates a 1.1.0.x package should create a release in this channel
Each package has its associated code stored in a separate Azure DevOps repository and a separate Azure DevOps pipeline configured.
These Azure DevOps pipelines use the Octopus Deploy step to create a release of the project defined above using the packages folder argument (to provide the package version for the single new package version that was pushed in a previous step) and a version generated from the current branch name and a semantic version mask character.
Normally this approach works great because we can move from version to version without having to manually specify the channel name anywhere in Azure DevOps.
Our specific problem is caused when building Package 2, because even though Octopus detects a “User Specified” version of Package 2, the release plan for the black channel is still viable because it can reuse previously pushed packages to create a release in that channel.
Would it be possible to see an example of the build log for the create release step? It would be interesting to see the logic it is applying when determining the release plan.
I believe you touched on this earlier but just to clarify what I’m seeing, would I be correct in saying that the deployment step that uses Package4 is scoped to Channels Purple and Red and the step that uses Package2 is only scoped to Channel Red?
If you set channel Red as the default channel does this build work? And then do builds for the Green and Purple channels also work?
If that doesn’t work then the only other option would be specifying the desired channel within the create release step.
Thanks for looking into this. Yes that is correct. When I set Red as the default channel then the build does work for Package2. The problem with this is that releases intended for Channel Purple for Package4 will go to Channel Red. This means that we would have to change the default Channel depending on what package and Channel we are working on. I will look into specifying the channel in the create release step for these specific releases. Thanks again