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:
- CI (internal CI, testing etc.)
- 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.