Issue: I’m currently running into an issue using a “Master Project” or “Orchestration Project.” It uses the Deploy a Release step for each project in it’s group, and the deployment condition for every step is set to IfNewer. On projects that use channels, though, I’ve noticed that it will always deploy the release if it is not the most recently deployed release.
Expected behavior: I would expect that when a project has DiscreteChannelRelease set to True (“Treat independently from other channels” in the UI) then it would not re-deploy the release.
Steps to reproduce:
Create a project with multiple channels and the Discrete Channels project setting
Create a release in the secondary channel, and deploy
Create a release in the default channel, and deploy
Create an orchestration project, that contains the “Deploy a release” step, and deployment condition set to “Deploy the release if it has a higher version than the current release in the environment.”
Create a release in the orchestration project, selecting the release in the secondary channel. It will deploy the project, even though the release for that channel is the latest.
Thanks for getting in touch! I’m sorry you’re hitting this unexpected behavior here. Unfortunately I haven’t been able to reproduce this issue after following your clear repro steps, however. I’m testing in my local instance which is running 2018.8.7, so it’s likely that it has been fixed between 2018.6.10 and now (perhaps included in this issue). Would you be able/willing to upgrade to see if this fixes the issue for you?
I would also like to confirm I’m reproducing this accurately. I’ve created a child project with two channels and two releases, one release per channel. The release in the secondary channel is version 1.0.1 and in the default channel 1.0.2. I created a release of the orchestration project, selecting the release 1.0.1 (that’s in the secondary channel) of the “child” project and deployed. The result in the log is The project My Web App will not be deployed because the requested release version (1.0.1) is not higher than the currently deployed or queued version (1.0.2).
I’ll also be happy to set up your version to test and attempt to find a workaround. In this case, would you be able to provide the deployment log from the orchestration project to give me the most context?
I hope this helps for the time being, and I look forward to hearing back!
I can absolutely do an upgrade to see if the issue resolves itself. Worst case I’m happy to do a dump of all logs and/or a screen share. I don’t want to waste your time if the issue is resolved by an upgrade, though, so I’ll do that tonight and test things out.
Apologies for all this, turns out it’s on us. The release we were referencing was created first, but the project uses a custom versioning based on the date, and occasionally appends a hyphen and additional text after it. Somewhere along the way I missed the following in the SemVer 2.0 specs:
Numeric identifiers always have lower precedence than non-numeric identifiers.
Because of that, we had release 1.18.10.2-13.11-DataOnly comes before 1.18.10.2-13.29 as it’s not just comparing numeric info. If you can confirm that precedence is followed in Octopus, we can close this and I will reach out to the product owner to discuss moving to a proper SemVer 2.0 versioning scheme.
Thanks for following up and letting me know you’ve found the reason for this behavior. You’re correct that Octopus follows the SemVer 2 versioning scheme.
Don’t hesitate to reach out if you have any further questions in the future.
