Octopus Deploying latest, not requested release

Octopus Server
, ,
1

Hello all -

I cannot explain this odd deployment glitch.

I have a CI build which is building 9 projects and registering them as build say 2.2022.0.223. I then create a release 2.2022.0.223 in all the projects, as well as a master project which has steps to deploy all those 9 dependent builds.

After my release was created, in a freakish accident, another configuration on My CI server inadvertently created a 2000.0.0.0 release which is now considered the “latest” for obvious reasons.

When my CI Server built release ‘2.2022.0.223’, it included an Environment name in the request so it should deploy to that environment. However, despite this, Octopus delivered the LATEST release rather than the release that was asked to be generated.

Thinking maybe this is a TeamCity plugin issue maybe, I go to Octopus, and I go to the actual release 2.2022.0.223 and explicitly say “Deploy this to the CI server.” It is still taking the “latest” build (20000.0.0.0) even though I am providing (or think I am providing, anyway) the exact build # that I would like to deploy.

I went back to a previous release in Octopus, 2.2022.0.220 and deployed it to the CI server and it did not deploy this 2000.0.0.0 release. It deployed as expected.

I can delete this offending release 2000.0.0.0, but can anyone explain what is happening? May be an octopus bug? I want to be sure I understand the release selection mechanism here to troubleshoot issues going forward.

Thanks

2

I deleted all the “last” releases in all the lower level projects. Of course my attempt to redploy the master project at build 223 failed, because that was somehow created with all the “2000” builds and now those builds were missing.

I went to delete and recreate the 223 build in the master project, and I notice that Octopus had selected “latest” as default in all the child projects. So it does appear to be a TC plugin thing - or an Octo API thing… that creating a master project selects the latest versions, not the last or a certain version even if supplied. Not sure that “last” is achievable via the API.

4

Hi @jesse.wolfe,

Thanks for getting in touch!

There is a difference here between package versions and release versions. When you create your release (2.2022.0.223) Octopus will assign specific package versions to that release. It isn’t possible to change these packages once the release is created. Which is why your old release worked and the new one failed after deleting the packages.

When creating a release via the API Octopus will default to the latest package unless a specific version is stated.
You can specify the desired version by using the --package or --packageversion arguments detailed here: Create release - Octopus Deploy

Regards,
Paul

5

This did the trick, Paul. Thanks.

1 Like
6

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