Can Channel Version Rules be Applied to the Release Version Number?

[OctopusSchaff]

I have a release that looks like this:

The version of the Release is 0.0.0.359-test-feature-branch. It has two packages that each have independent version numbers (1.0.37 and 1.0.9).

The version of the release is meaningful and it would be really nice if I could put channel version rules on it.

The versions of the packages are re-used for all release types and are not meaningful at the channel level.

When I go into the channel screen and try to create a rule without a package, I get this error:

Is there a way I can apply a channel version rule to the release’s version number? (Not a package version number.)

[Kenneth_Bates]

Hi @OctopusSchaff,

Thanks for getting in touch! Good question, and while I have an idea I’m not positive it addresses exactly what you’re looking to do.

Are you wanting to automate the way the releases are versioned based on which channel you select at create release time? If that’s the case, instead of version rules against a package step, you could create a custom release versioning template which has some channel-specific special variables available for use there. For example, if you’re wanting releases in the default channel to simply be lastmajor.lastminor.lastpatch.nextrevision, the following template will still do this, but releases created in Branch Testing will append -test-feature-branch to their release versions.

#{Octopus.Version.LastMajor}.#{Octopus.Version.LastMinor}.#{Octopus.Version.LastPatch}.#{Octopus.Version.NextRevision}#{if Octopus.Release.Channel.Name=="Branch Testing"}-test-feature-branch#{/if}

These release versioning templates are defined under the project’s Deployments > Settings page, as shown below.

I hope that helps! Let me know if that doesn’t help with what you’re looking to do specifically, and I’ll be happy to have another go.

Best regards,

Kenny

[OctopusSchaff]

I am realizing that the channel version rules will not work as I was hoping.

My auto build system creates the version number and then calls the Octopus API to create the release. When I make the release via the API, I just pass in the version number using json like this:

{
  "Version": "0.0.0.359-test-feature-branch",
  "ChannelId": "Channels-1345",
  "SelectedPackages": [
	{
	  "PackageReferenceName": "",
	  "ActionName": "Upgrade Application Helm Chart",
	  "Version": "1.0.37"
	},
	{
	  "PackageReferenceName": "",
	  "ActionName": "Toggle Latest Endpoint",
	  "Version": "1.0.9"
	}
  ],
  "ProjectId": "Projects-1025"
}

However, the code that creates this json can be modified by my application developers. So I was hoping to make a way to prevent them from pushing pre-release builds into my main channel.

My hope was that I could make Octopus reject the API call to create the Release in the main channel, if the release’s version had any pre-release (1.0.0-pre) or metadata (1.0.0+meta) values.

If this can’t be done, I may be able to enforce it using Tenants. But I was hoping to not have to use Tenant settings because all Tenant settings are lost when a project is copied. (I am making a project that will be used as a template (and hence, will be copied a lot.))

[Kenneth_Bates]

Hi @OctopusSchaff,

Thanks for following up and for the clarification. Sadly there’s no mechanism to control channel-selection based on the release version passed in. The closest to addressing this might still be channel version rules.

While that allows automatic package version selection based on the channel passed in, it also can automatically select the best channel based on the package version passed, based on which channel the package version is applicable for based on the version rule. You’d want to make sure only one channel is an option, so you’d need to explicitly exclude the pre-release versions in any other channels, and you would also need to ensure you have a package’s version in lockstep with what you’re versioning your releases as.

Really not sure this will help in your scenario at all, but thought I’d throw it out there.

Sorry to say I can’t think of a more satisfactory answer, but please let me know what you think, or if I can try to help with anything else moving forward!

Best regards,

Kenny