Channel Rules not working correctly for Deploying Releases

I’m seeing a few different unexpected behaviors with channel rules when attempting to use them for steps which deploy the release of another project.

  1. The “Pre-release tag” regular expression can also be used to match against metadata. This is actually desirable, but I’m hesitant to use it unless it’s intended and therefore won’t ever be changed

  2. The “Package step(s)” always displays “No results found” in the drop down when attempting to add a step for a Version Rule via the UI. I actually didn’t realize this issue for a while because we use a script to set everything on the project including version rules, which actually works correctly and fills in the steps that will deploy the release of another project. After setting the version rule via a script, the steps will show up and remain there even after modifying the version range or regex and saving via the UI.
    It’s worth noting that using the UI only makes it impossible to use, since it will throw an error when attempting to save saying “Version rules must specify a package step”.

  3. The “Version range” option does not seem to like wildcards, at least when using an inclusive range (I didn’t test otherwise though).
    We have a project that deploys the releases of other projects (which I’ll just call sub-projects for now)
    Within that main project, there’s channel rules to only pick up releases up to a certain version for the sub-projects.
    One of the sub-projects has the following releases:

The goal for the “hotfix” channel of the main project is to release up to the latest version of 20180301 to get any patches. To do so, we tried using (,20180301.0.*] but when we do that and then try to create a release for that channel, we get the following error:
The ‘versionRange’ parameter ‘20180301.0.1’ was not a valid NuGet version-range (see

For now, we are working around this by bumping the minor version and using an exclusive range, but I believe that the wildcards in a range should be working.

Thank you for the help!
Let me know if I can clarify anything.

Adding one more issue :slight_smile:
4) I also just discovered an additional discrepancy between deploying a release and deploying a package.
When choosing to deploy the latest release of a project, it will pull the latest release by date and not the latest release by version number as I’d expected. For example, I created 20180401.1.0 of a “sub-project” and then accidentally happened to create 20180201.1.0. When creating a release for the main project, it pulled, by default, the 20180201.1.0 release rather than the 20180401.1.0. I verified that 20180401.1.0 was in the list of versions I could select manually to be sure the version rules were still including it.

Hi Andrew,

Thanks for getting in touch! I’m terribly sorry you’re hitting these unexpected behaviors. We really appreciate you providing these reports and input to help us keep improving Octopus. I’ll answer your questions individually - firstly, which version of Octopus are you currently running?

  1. Would you be wiling to expand a bit on the behavior you’re hitting here, such as which metadata is the regex matching against? I’d like to test and/or confirm precisely the behavior here. :slight_smile:

  2. It looks like you’re hitting a known issue which was resolved in 2018.8.6 and you can reference the bug in the following link. If you’re running a version prior, would you be able to upgrade and confirm this is fixed?

  1. Unfortunately our version range doesn’t support wildcards as mentioned in that NuGetVersioning doc page you’ve linked to. It’s been mentioned in the past (see this enhancement), and it’s been suggested on our UserVoice site at the following link. I’d urge you to throw it some votes to boost its visibility. :slight_smile:
  1. I’ve been able to replicate this discrepancy between release versions and package versions, and I’ve reported this bug at the following link for you to track.

Thank you again for your detailed and helpful reports and input! I hope this helps, and please don’t hesitate to reach out if you have any further questions or concerns moving forward. :slight_smile:

Best regards,


Thanks for the quick response Kenny.

  1. We are using the “Deploy a Release” step and the main project is selecting the latest release of other projects to deploy. For hotfixes, we are adding a “+hotfix” to the end to make use of the metadata in order to easily identify hotfixes in the dashboard. In the channel rules, we only want to select any releases that do not have a pre-release. Originally we had put “^$” as the channel rules, but that was excluding everything with a +hotfix on the end. I updated the channel rules to be “^([+]hotfix)?$” and it then correctly pulled in releases, such as 20180401.1.0+hotfix.
    Let me know if I can provide more details

  2. Thank for letting me know this has been resolved. We were using 2018.8.3, so I went ahead and upgraded our version to 2018.8.12. I’ve verified that it’s working correctly now in the newer version.

  3. Thanks for the information here as well.

  4. Great, we’ll look forward to the fix

Hi Andrew,

Thanks for following up, and that’s great to hear the upgrade fixed #2.

Unfortunately I still don’t think I fully understand your requirements regarding #1. I apologize about the back and forth regarding this. When testing this, it seems to work as expected, and in the same way as defining the same rules for packages. This is how I’ve set it up:

Default channel to accept only non-hotfix releases of the child project, and my Hotfix channel to accept only hotfix releases of the child project.

When creating a release, it correctly selects the child project’s release version based on the rules.

Default channel:

Hotfix channel:

Is this similar to what you’re after, or am I still misinterpreting? :slight_smile:

I look forward to hearing back!

Best regards,


Hi Kenny,

Thank you for taking time to investigate this further.
I apologize as I think I did a poor job of explaining my first question.

I am also seeing the same behavior you mentioned where the “pre-release tag” rule matches metadata.
At first I had expected that a version such as 1.2.3-alpha+build1 would be parsed down to:
Version = 1.2.3
Prerelease = alpha
Metadata = build1

Thinking it was parsed that way, I was expecting the prerelease tag regular expression of the channel rule to only match against the string “alpha” rather than “alpha+build1”, which includes the metadata.

In other words, I was originally expecting that a channel rule with prerelease tag regex “^alpha$” would end up matching a version such as 1.2.3-alpha+build1, however it would not match it since that regex does not match what it is actually checking against, which I believe to be “alpha+build1”.
So it appears that the regex is not just a match of the prelease tag but actually everything after the “-”, which includes the metadata.

This is perfectly fine and I don’t consider this to be a bug. However, I wanted to verify that this behavior was intended (and therefore won’t be changed) before creating an expression that expects metadata such as “+build1” to be included in the prerelease tag regex check.
My concern was that this potentially could be considered incorrect and eventually the prelease tag regex might be changed to only match against the prerelease tag. If I end up relying on the metadata to be part of the match, any future change could affect our use of the prelease release regex part of the channel rule. So, I just wanted to be sure this behavior was the intended behavior before relying upon it as it is.

Hopefully that helped clarify, but please let me know if I can clarify anything further.

Thank you!

Hi Andrew,

Thank you for expanding upon the question, it really helped. :slight_smile:

Short answer is this is expected and intended behavior. Since your versions are valid SemVer2, and the regex to define the pre-release tag is intended to be as flexible as possible, it’s a safe bet that this behavior won’t change. If you’d like to double-check before an upgrade, you can use our release compare tool to see the release notes between every version.

Let me know if you come across any further questions or concerns moving forward!

Best regards,


Okay great. Thank you again for the detailed and quick responses!

Hi Andrew,

You’re very welcome! Please don’t hesitate reaching out if you have any further questions or concerns in the future. :slight_smile:

Best regards,


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.