Packer: Feature Request: Pretty Print Build Duration (aka Time)

[ladar]

My builds have gotten longer, and I've run out "low hanging fruit" optimizations. But the need for speed persists, and as a result I'm trying to get more scientific about tracking build durations for the various distros on the various hypervisors/CPU types I currently target.

With a lot of effort, I can extract duration info using the debug log (or the spiffy new -timestamp-ui option) but thought it would be nice, and helpful to all, if packer simply printed how long it takes to build a particular configuration along with the "all finished" message. It's hard for me to track start/stop times when I build a bunch of machines 1 or 2 at a time. Which why I'm asking that:

Build 'generic-rhel8-vmware' finished.

Become:

Build 'generic-gentoo-vmware' finished in 1 day 3 hours 24 minutes 25 seconds.

A superfluous improvement might would printing the duration on a preceding line in ISO 8601 format when the -machine-readable flag is used, like so:

==> generic-gentoo-vmware: P1DT3H24M25S
Build 'generic-gentoo-vmware' finished in 1 day 3 hours 24 minutes 25 seconds.

In my world, errors, and cancelled builds would also print a duration like so:

Build 'generic-openbsd6-vmware' errored: Build was cancelled after 2 minutes 2 seconds.

For extra credit, the ISO download (and possibly the vagrant-cloud/docker-push post processors could alos print out durations in the same format (pretty/machine readable), upon completion. That would make it easier for number munchers like myself to track those network intensive steps separately.

In theory all of the major 'steps' or 'stages' could print durations.. but from my point of view, it's the network heavy preparation, and publish/deploy stages, that are statistically the most significant, and thus worth tracking separately. (In theory individual provisioner/post processors could print durations using generic logic, but that would be noisy, so if we go down this road, perhaps have each "stage" print it's duration, ie download complete/vm setup (aka prep stage) -> build complete (aka provisioning step) -> post processor completion.

For completeness I'll request this feature print other statistics, like CPU time, disk IO, and network transfer; but I realize those values will be harder for packer to track/report across host platforms/providers/plugins.,, so you should only consider additional statistics if your vying for the title of "teacher's pet."

@azr if you make the change discussed in #7132, I think, it would probably be easy to add duration tracking at the same time (not sure though). I say that because in theory, a stopwatch could start when a build begins (not when packer begins).. and record stop points when control passes between plugins. And as I under your plan for #7132 it would involve adding code that is run when control is passed between plugins..

It's probably obvious, but worth noting that the start duration tracking for -parallel=true would begin at the same time for all of the build configurations, while -parallel=false would cause the stopwatch to start when a particular build actually begins, which is what I have trouble separating.

P.S. I've already started using packer builds as an internal benchmark of sorts, whenever I get new hardware online, but my numbers are crude. With this feature I could track duration over time, and if anybody is interested, I could eventually write up a summary of what I find, for all to read.

[azr]

Hey @ladar ( happy new year ! ), this is a good idea I think.
I'd display the time of any step - if it takes more than a threshold parameter - and then display the total time in any case.
This would make the pr simple by avoiding a step to have to know about duration or the scheduler to have a list of watched steps.
Giving focus on slow steps.

[EwiththeBowtie]

I'm taking a look at this as my first issue. Wish me luck!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.