Package version does not satisfy channel rules

3 days ago, my DEV team reported that TeamCity was, all of a sudden, failing to create a new release in Octopus.
After verifying the packages exist in Artifactory and that Octopus can see them when I “test” the feed, I attempted to manually create a release and am seeing the error message in the subject, when I hover my cursor of the Exclamation Mark next to the Last package version. There are no versions listed in the Latest column. I was able to manually create a release, using the version number of the latest packages, but when viewing the packages inside the release, they don’t say "Published ", but are stuck “Loading…”.

Here are the relevant logs from TeamCity:

[2016-03-17 15:01:16,333] out - Handshaking with Octopus server: http://octopus/
[2016-03-17 15:01:16,975] out - Handshake successful. Octopus version: 3.3.1; API version: 3.0.0
[2016-03-17 15:01:16,979] out - Finding project: ActionManagement
[2016-03-17 15:01:17,425] out - Finding deployment process for project: ActionManagement
[2016-03-17 15:01:17,658] out - Finding release template…
[2016-03-17 15:01:18,112] out - Resolving NuGet package versions…
[2016-03-17 15:01:18,114] out - The version number for step ‘DeployFiltersViewModelAPIWebApp’ cannot be automatically resolved because the feed or package ID is dynamic.
[2016-03-17 15:01:18,114] out - The version number for step ‘DeployActionManagementPackage’ cannot be automatically resolved because the feed or package ID is dynamic.
[2016-03-17 15:01:18,114] out - The version number for step ‘DeployCaseEmailService’ cannot be automatically resolved because the feed or package ID is dynamic.
[2016-03-17 15:01:18,114] out - The version number for step ‘DeployHubSyncService’ cannot be automatically resolved because the feed or package ID is dynamic.
[2016-03-17 15:01:18,114] out - The version number for step ‘DeployTriggerService’ cannot be automatically resolved because the feed or package ID is dynamic.
[2016-03-17 15:01:18,115] out - The version number for step ‘DeployCaseMigrationService’ cannot be automatically resolved because the feed or package ID is dynamic.
[2016-03-17 15:01:18,115] out - Using version number provided on command-line.
[2016-03-17 15:01:18,115] out - Release plan for release: 19.1.26.81
[2016-03-17 15:01:18,115] out - Steps:
[2016-03-17 15:01:18,116] out - # Name Version Source
[2016-03-17 15:01:18,116] out - — ------------------------------ --------------- ------------------------------------
[2016-03-17 15:01:18,116] out - 1 DeployFiltersViewModelAPIWebApp ERROR Cannot resolve
[2016-03-17 15:01:18,116] out - 2 DeployActionManagementPackage ERROR Cannot resolve
[2016-03-17 15:01:18,116] out - 3 DeployCaseEmailService ERROR Cannot resolve
[2016-03-17 15:01:18,117] out - 4 DeployHubSyncService ERROR Cannot resolve
[2016-03-17 15:01:18,117] out - 5 DeployTriggerService ERROR Cannot resolve
[2016-03-17 15:01:18,117] out - 6 DeployCaseMigrationService ERROR Cannot resolve
[2016-03-17 15:01:18,117] out -
[2016-03-17 15:01:18,118] out - Package versions could not be resolved for one or more of the package steps in this release. See the errors above for details. Either ensure the latest version of the package can be automatically resolved, or set the version to use specifically by using the --package argument.

The Channels for this Project are just the Default (Lifecycle inherits from project) and has no version rules.
The project has the settings:
Release versioning - Generate version numbers using a template
Version template - #{Octopus.Version.LastMajor}.#{Octopus.Version.LastMinor}.#{Octopus.Version.NextPatch}

Could the problem be that we use 4 numbers in our versioning, not 3? If so, why did it work fine for a year and break now?

For what it’s worth, I changed the version template to use 4 numbers, but it didn’t help.
I also trying changing release versioning to get the release number from the package, but that didn’t work either.

Hi Peter,

Thanks for getting in touch! I am going to hazard a guess that it isn’t the package number itself here but the feed listed on the package steps.
Can you have a look at your process for me and see what feed is listed? Is there any reason that this would have changed recently?
Did you upgrade versions and then this occurred? Does it happen for old releases or only new releases?

Hopefully an answer above will help troubleshoot this problem!
Vanessa

I’m not sure if your questions are about Octopus, TeamCity or Artifactory.
Here is our process:

  1. Code is created and merged into TeamCity
  2. DEV creates a new release in TeamCity, which connects to Octopus and uploads nugget packages to a local Artifactory repository (nuget-confirmit-SF-saas-local). During this process, TeamCity creates the release automatically in Octopus.
  3. Nuget packages replicate to other Artifactory servers around the world.
  4. We deploy the release to various environments as needed.

The feed has not changed, as far as I know.
I’m not involved in upgrades of TeamCity, Artifactory or Octopus, so I have no idea when each get upgraded.
I don’t understand your question “Does it happen for old releases or only new releases” - TeamCity can only create new releases, from what I’m told. If I manually create a release in Octopus, I get the message “Package version does not satisfy channel rules” even before I pick any release number or packages.

We are using the following versions:
TeamCity Enterprise 9.1.6. (build 37459)
Artifactory 4.2.2 rev 40049
Octopus 3.3.1

I think we figured out the problem.
After some trial and error, it appears that Octopus requires at least one unscoped feed. I had edited the scope on the unscoped feed to include the specific environments we intended for it to use, but there were no messages saying I shouldn’t do that. =)
This might be documented somewhere, but maybe this caveat should be made more obvious to people? =)

Hi Peter,

I agree I can add something do the documentation as this does come up now and again.
Where do you think you would have looked/found it?

Vanessa

When click on the search on the right side, when creating a release.
It wasn’t working, but no error message was visible to indicate why.

I don’t know how feasible this would be, but it would be pretty nice to have a banner that would appear if something were misconfigured like this, or some requirement for a process to work was missing. But that might be too much to ask. =)

Hi Peter,

I have added a note to our documentation, hopefully it is not too hidden. It is pretty unlikely that we would be able to put anything into our UI for this specific problem. But we will keep an eye on how often this comes up as it would help us make it a priority.

Thank you for the feedback.

Thanks,
Daniel