Issue with showing how long a step runs in a deployment if that step is skipped due to the Role it's assigned to, is not on the Machine that is being deployed to

Legacy Usability
1

Hello,

We are using version 2018.7.7 and noticed an odd item when a deployment includes steps that will not actually be run on a server during that deployment because that Role is not assigned to the Machine being deployed to. What we end up seeing is that the time it displays overall that it took to run the step is the overall time at that point in the deployment process, not how long the step itself took. Here’s an example:

image
image.png1597×502 36.5 KB

You will notice that the “Create Delete Combit Files Task” took 3 seconds to run, but the “Deploy Notification Engine” step, which will be skipped because no machines being targeted for deployment had that role, took 2 minutes and 8 seconds. If you look at the detailed information between the two steps, you will see that only a second has gone by. We would expect to see that the “Deploy Notification Engine” step took 1 second to run.

This isn’t causing our deployments to slow down, but more than likely, just an UI issue that we wanted to pass along.

If you have any questions, please let me know.

Thanks,

Matt Heinzelman
Automation & Installation Engineer

Cartegraph

3

Hi Matt,

Thanks for getting in touch and thanks for reporting this.

We reproduced this today and unfortunately this is a side-effect of the way the task log files are written. At a certain point during the execution of your deployment process, a block is added to your task log file for step 22, and then when step 22 actually starts, we’re calculating the run-time based on the difference, which is why that timing’s not intuitive.

We’ve raised an issue with the usability team internally so this is on their backlog of things to fix. But you’re right, this definitely isn’t causing your deployments to slow down on the server at all, it’s a UI bug only.

If you’d like a GitHub issue to track this, please let me know, otherwise we’ll investigate/fix this one internally.

Cheers
Mark

4

Hi Mark,

Thanks for the follow up! I think it would be alright if the team just fixes it internally. Since it’s just an UI issue, I don’t think a GitHub is needed.

Thanks,
Matt

6

Hi Matt

Just a quick note to say that this has been resolved, and shipped yesterday with 2019.1.1.

Happy deployments!

Cheers,
Matt