Latest release logic based on DeploymentHistory Created date and not CompletedTime

I believe there is a bug in the logic which selects which release was last deployed to a particular channel/pipeline; I believe this is down to the DeploymentHistory “Created” datetime field being used instead of the “CompletedTime” field.

To recreate this:

  1. If a deployment is scheduled for sometime in the future and queued up; e.g. for 20:30 in the evening
  2. And a deployment of a different release to the same channel is immediately deployed manually to that same channel (before the scheduled deployment actually runs); e.g. at 18:00 on that same day.
  3. Then, the latest release displayed in the project overview and dashboard view will be the manually triggered release from 18:00, and not, as desired/expected, the scheduled release which occurs later on that evening

Can you please verify if this is indeed the way the logic is currently working?

we are running Octopus Deploy version 2019.3.5 LTS

many thanks

Hi @paul.kelly!

Thanks for getting in touch, and your research surrounding this matter. I’ll do some verification on this and get back to you ASAP!

Hi Paul

Really sorry that we let this ticket fall through the gaps. Not the service you deserve from us.

Looking into it, your surmise is correct - it does order by the created date here (nice sleuthing btw).

This is not ideal in the situation you have described. Talking to some team members who have experience in this area, it does appear that scheduled deployments weren’t fully taken into account in this implementation.

Now, we think we might have a solution to make the project dashboard show the correct data - it can and does make sense with the highlighting of the current and previous deployments on this view.

However, with the main dashboard, this shows things ordered by version (descending). We’re currently having some discussions internally about what the right behavior here should be.

Unfortunately, this is one of those areas that serves many masters. Changing it to suite one scenario often breaks it for someone else’s scenario.

We’ll continue to drill into it, and we’ll give you an update as soon as we’ve got some more concrete ideas.

Once again, apologies for the delay in getting back to you.


Thanks Matt,

I think you need to be consistent across the entire product and show what was the last deployed version, and this is not necessarily the “latest version” semantically; for a couple of reasons that spring to mind; Rollback is more often achieved through deployment of the previous version of a release and also the versioning approach may have changed during the lifecycle of a particular release.

We would definitely expect the dashboard view to behave similarly, as this is where our release managers will look to verify deployed versions.

Many thanks,

I’d love to know in what scenario someone would want the dashboard to show the newest package ever deployed vs what’s currently deployed.

Hi @paul.kelly, @seanl

Apologies for the delay - we’ve been deep diving into this and getting a fix sorted, but unfortunately we dropped the ball on communications.

We concur that its behaving wrong here, and we’ve raised an issue you can track while we get a fix in place. We’ve got something almost ready - we should ship in the next few days, most likely in 2019.10.7 or thereabouts.

Hope that helps.