Improve how timings are presented
What does this merge request do and why?
This MR tidies up how timings are presented for gdk update
and gdk reconfigure
to make them more consistent and less confusing.
How to set up and validate locally
Run a make update
(run make
instead of gdk
so the branch is not changed) and you should see at the end:
$ make update
--snip--
--------------------------------------------------------------------------------
Updated successfully as of 2023-03-30 14:03:59
platform-update: 58 sec(s)
preflight-checks: 17 sec(s)
preflight-update-checks: 2 sec(s)
gitaly-update: 80 sec(s)
gitaly-git-pull: 5 sec(s)
gitlab-shell-update: 8 sec(s)
gitlab-shell-git-pull: 5 sec(s)
gitlab-update: 162 sec(s)
gitlab-git-pull: 14 sec(s)
gitlab-metrics-exporter-update: 7 sec(s)
gitlab-workhorse-update: 33 sec(s)
jaeger-update: 1 sec(s)
object-storage-update: 0 sec(s)
Took 393 sec(s) total
--------------------------------------------------------------------------------
As well as the following for a gdk reconfigure
:
$ gdk reconfigure
--snip--
--------------------------------------------------------------------------------
Reconfigured successfully as of 2023-03-30 14:06:58
Took 19 sec(s) total
--------------------------------------------------------------------------------
Impacted categories
The following categories relate to this merge request:
-
gdk-reliability - e.g. When a GDK action fails to complete. -
gdk-usability - e.g. Improvements or suggestions around how the GDK functions. -
gdk-performance - e.g. When a GDK action is slow or times out.
Merge request checklist
-
This change is backward compatible. If not, please include steps to communicate to our users. -
Tests added for new functionality. If not, please raise an issue to follow-up. -
Documentation added/updated, if needed. -
Announcement added, if change is notable. -
gdk doctor
test added, if needed. -
Add the ~highlight
label if this MR should be included in theCHANGELOG.md
.
Closes #1779 (closed)
Edited by Ash McKenzie