OK then Broken: Automatic Release Creation With Channel Versioning Rules

Legacy Modelling
1

Hi,

I think I have a very similar problem / scenario as is described here:
https://help.octopusdeploy.com/discussions/problems/44175-automatic-release-creation-does-not-follow-channel-versioning-rules

However, the problem is different because until recently our CI worked like a charm, and now I somehow broke it.

To recap:

We have two packages that make up a release:

  • SuperSolution.WindowsService
  • SuperSolution.WebApi
    The two packages are always built together, so there’s always two with identical package version numbers.

We have two quite different Deployment Processes in the Octopus Project:

  1. CI (internal CI, testing etc.)
  2. Public Release (generate installer etc.)

The versioning rules are:
0.0.. for internal CI builds
1...* for Public Releases

I set up the CI process with automatic release creation (and deployment). Using channel versioning rules, I could restrict that the internal CI will only create a new release using the 0.0.. packages (never taking any 1...* packages). This worked perfectly until two days ago. What seems to have broken it was the following:

Because I wanted to test a ‘Public Release’ hotfix on our CI infrastructure before taking it to the customer, I created a release manually that overrides the channel versioning rules (i.e. deploying a 1...* release to CI). I even had to check a box in the Octopus UI to “Force Version Selection” - so the CI channel seems to be quite aware of that this is not a package intended for it.

Anyway, since I did that the CI automatic release creation is broken:
When a new pair of packages is published:
SuperSolution.WindowsService.0.0.22.1234.nupkg + SuperSolution.WebApi.0.0.22.1234.nupkg

The Automatic Release Creation makes a Release as such:
SuperSolution.WindowsService.0.0.22.1234.nupkg + SuperSolution.WebApi.1.4.0.177.nupkg

So, somehow that ‘Force Version Selection’ has disabled the version restriction rule for the ‘non-triggering package’. I tried removing the rule and adding a new one (with identical rules) to no avail. The problem seems temporarily removed when I delete all the nuget ‘Public Release’ packages which are newer than the one I took over to the wrong channel. So this ‘take newest’ logic in the ARC is only broken going back to that fateful release which I illegitimately promoted. (or demoted ;o) )

I basically had to switch of ARC now… which is sad and cumbersome. :frowning:

2

Hi Fabian,

Thanks for getting in touch! I’m sorry for the delay in getting back to you here. Looking at your setup here, I believe the best way to continue with your automation would be to use one of our plugins for your build server over ARC. They give you the option to create a release, with different configuration options, as a build step. Our ARC feature, whilst useful, is not recommended over our build server extension.

The following documentation pages have information on using our extension/plugin for creating a release.
VSTS/TFS: https://octopus.com/docs/api-and-integration/tfs-vsts
TeamCity: https://octopus.com/docs/api-and-integration/teamcity

Let me know if the above helps resolve your issue, or if you have any further questions. :slight_smile:

Best regards,
Daniel

3

Hi Daniel,

I thought about creating the releases in a build step. However, I found a more simple, yet a bit ugly solution: for the CI builds, I now just use a higher build number than for the releases: 100.x.x.x
That makes Octopus always consider those packages the “latest” and they will always correspond to the “last”.
So that was my workaround… idk, we may close this issue, I’ll leave it at that. But it’s still a bit odd what happened I find.

Best,
Fabian

4

Hi Fabian,

Thanks for getting back. I guess that is a viable workaround, so long as it works. :slight_smile:

ARC was not designed to be too smart, which is why we suggest the plugin extensions. As they give you the ability to specify package version, whereas ARC simply takes the latest package.

Let me know if you have any further questions here or run into any issues.

Best regards,
Daniel