we plan to start using lifecycles and channels similar to the way is demonstrated on the channels video, i.e. one channel for QA only, one channel for Release Candidates, which will get promoted from Staging to Production (and beyond.) each environment really has 10 environments for our multiple tenants.
each night, we run a build for QA and for Staging and will create releases in each of the QA and Release Candidate channels. later (in the early morning hours), we use calls to octo.exe to deploy to the 10 QA sites and the 10 Staging sites.
with octo.exe, we can deploy a release and specify the latest release, but since we will have just created 2 releases, how can we specify to deploy the latest release from a particular channel (i.e. so we can deploy the latest QA channel release 10 times, and deploy the latest Release Candidate release 10 times)
Octopus will choose the “latest” release for a project based on the version number of the release. Unfortunately this means just asking for the “latest” version will choose whichever version has a higher number from your channels.
If you have multiple channels and you want to target them specifically, you’ll need to keep track of the version number that was created for that channel and specify it explicitly.
I’m surprised that this isn’t something more people would want. In our case, the QA build will be building at least one minor version ahead of the Staging/Release Candidate build, so the QA release version will always be higher than the Staging release version.
does the list-releases api call specify the channel that each release belongs to in the results?
Thanks for that feedback. I’m inclined to agree that there’s something missing here.
If there was an additional --channel= parameter you could pass to the ‘deploy-release’ command would that solve your issue?
The /api/releases and /api/projects/{projectId}/releases API calls will return a channel Id along with the list of releases, so you should be able to use that in the meantime.
I think I’ve wandered down a path of red herrings, I’m afraid
For some reason I’d understood that the change to the command-line tools that enables this support was included as part of 3.3.10, but I must have been looking at another issue as I now see is was part of 3.2.13.
I then conflated this with noticing that the ‘Deploy Release’ runner didn’t have a ‘Channel’ field (like the ‘Create Release’ runner does) and that the ‘Release number’ field was mandatory - I’ve now remembered that ‘latest’ is a valid version number!
Using ‘latest’ and specifying the ‘–channel’ switch works fine!
The --channel argument is not available (and not needed either) when promoting a release from one environment to another as the channel has already been specified when the release was created.
