We have several channels that are used to deploy packages independently. Each channel has a primary package and one or more secondary packages. When I’m creating a new release, I would like the version to be taken from the primary package (or a package that is configured to provide the version number.)
This is something like the “Use the version number from an included package” for Release versioning from the project settings page, but per channel.
I tried using a template, like
#{Octopus.Version.Channel.LastMajor}.#{Octopus.Version.Channel.LastMinor}.#{Octopus.Version.Channel.NextPatch}.#{Octopus.Version.Channel.NextRevision}
but it’s not generating the correct version.
Thanks for getting in touch! I’d love to help! In order to attempt to replicate what you’re seeing, could you provide a little more information?
Which Octopus version are you currently running?
Could you send me screenshots of your package, project process and channel version rules?
What’s happening when it’s set to the package and the channel is selected? Is it picking the wrong package?
Could you explain a specific example of which packages are included and what release version you’re wanting to see?
The template looks like this:
#{Octopus.Version.Channel.LastMajor}.#{Octopus.Version.Channel.LastMinor}.#{Octopus.Version.Channel.LastPatch}.#{Octopus.Version.Channel.LastRevision}
The projects are
MainProject current version: 2.10.5.4534
DependencyProject current version: 1.3.0.4534
The previous release was 2.10.5.4 so now the version number is 2.10.5.5
But I would like to have the current version number to be 2.10.5.4534
If I create a release with version 2.10.5.4534, then change the template to use Channel.NextRevision} for the last part,
the next release will have 2.10.5.4535, which is not necessarily correct.
So what we need is to use the version of a primary project, defined per channel.
Or to be able to select the version template per channel.
When you use the template of #{Octopus.Version.Channel.LastMajor}.#{Octopus.Version.Channel.LastMinor}.#{Octopus.Version.Channel.LastPatch}.#{Octopus.Version.Channel.NextBuild} it is per channel.
For MainProject Channel it would go 2.10.5.4534 -> 2.10.5.4535
and for DependancyProject Channel it would go from 1.3.0.4534 -> 1.3.0.4535
I don’t know if I understand the exact problem. Could you give an example of how your releases should progress for a few iterations so I can understand. I am not sure why you jump from 2.10.5.4. to 2.10.5.4534 and then what would come after that.
Sorry if I am missing something here. I feel like I must be.
Vanessa
It’s correct, "For MainProject Channel it would go 2.10.5.4534 -> 2.10.5.4535"
but that is not what I want.
Because the 4534 and 4535 are revision numbers and do not increase +1…
They are taken from TFS and added to the nuget packages.
And I need the Octopus version template to use them from the package.
You can base your releases on a package. It is part of the project settings. Instead of choosing the template you chose the package step.
If your channels cannot share a package step that can be used as the version template, there are workarounds such as a dummy package step that will guide all channels with their own version where you build it to have the version you need but it is empty.
One more thing, can I use the #{Octopus.Version.Channel.LastMajor}.#{Octopus.Version.Channel.LastMinor}.#{Octopus.Version.Channel.LastPatch}.#{Octopus.Version.Channel.LastRevision} in steps?
I’m trying to use them to create a file name for the previous release, per channel.
Thanks for getting back to us! Those variables are special point-in-time variables which are only available when you are creating a release.
When you are deploying, and you ask for the “previous release” we want you to get an answer that is the “least surprising” answer based on your context at deployment time. For example, at deploy time you can ask for Octopus.Release.Previous.Number which will give you the previous release of the project which was deployed into the same machine/tenant/environment.
If Octopus.Release.Previous.Number will give you the answer you were hoping for, you could use something like System.Version.Parse() to pull it apart into its pieces so you can do calculations on those pieces.
After reading through the earlier conversations, I do feel like you are working hard to wrestle Octopus into a particular shape - and it makes me wonder if we’re missing a feature that would have helped you (and potentially other customers). To help me understand better, could you send through some screenshots of your deployment process, channels, and your releases with examples of what is working as you expected, and what wasn’t?
I feel like you want to be able to choose on each channel which step/package is used as the donor for calculating the version. “If I’m creating a release in this Channel A, use Step A. If I’m creating a release in Channel B, use Step B. Otherwise use Step C for all other channels.”
I apologise if that sounds painful, and like you’ve had to repeat yourself - text can be a lossy medium for sharing complex concepts like this one!
Hi, ref. “Octopus.Release.Previous.Number which will give you the previous release of the project which was deployed into the same machine/tenant/environment.”,
well I thought this will be the behaviour, but it doesn’t happen:
for DEV channel version = 2.7.0.4903
for UAT channel version = 2.6.0.4902.
The backup uses a variable called #{Octopus.Release.Previous.Number}.
When performing the backup for UAT, the file is DB_2.7.0.4903.bak while the previous version for UAT is 2.6.0.4827.
When performing the backup for DEV, the file is DB_2.6.0.4902.bak when it should be 2.7.0.xxxx
Ref "I feel like you want to be able to choose on each channel which step/package is used as the donor for calculating the version. “If I’m creating a release in this Channel A, use Step A. If I’m creating a release in Channel B, use Step B. Otherwise use Step C for all other channels.”
I would like to have a package per channel, to get the version from.
This way I can create one channel for each component and get the version from a package in that channel.
Thanks for getting back to me! I’ve spent some time researching this and you’re right - the Octopus.Release.Previous.Number is not in the context of the machine, nor is it in the context of an Environment/Channel/Tenant. It is simply the previous Release of that Project to anywhere.
But these variables also won’t help you because they are not taking into consideration enough context. For example Octopus.Release.PreviousForEnvironment.Number only considers the context of the Environment, but not Channel nor Tenant.
I feel like what you would be after is something like “just tell me what the previous Release was for a context just like this one I’m trying to do now.”
For example we could populate a variable called something like Octopus.Release.PreviousForMatchingScope. This would figure out the previous Release deployed to the same Environment and optionally filter further based on whether you are using Channels or Tenants.
Onto the other topic, it looks like we’ve got some UserVoice suggestions that line up with what you are saying too. I would recommend drumming up support on those suggestions, adding some comments with your scenario so we have more context when implementing something to help.
For now, the PreviousForEnvironment variable is good enough.
I tested its use to create the file names used for backup.
I’ll test it for release numbers as well.
I’m using channels to control the version numbers so that the developers in charge with releases will not create releases with wrong versions per channel.
So until that feature is available I’ll just tell them to pay attention :))
I’m using Octopus.Release.PreviousForEnvironment to get a handle on the release number for the correct environment.
As for the Octopus.Version.Channel variables, they are still not what we need, because the NextRevision is automatically incremented and not taken from a project/nuget.
So if the current version for the channel is 2.12.4.4906, when I create a new release, the version becomes 2.12.4.4907 while the nuget revision is 5019.
Thanks for getting back to me! In that case, make sure to head over and cast some votes and add details about your situation in our User Voice site. It will help us prioritise and then build the feature taking your situation into consideration.
