This metric records the number of times it sees a lint warning in the
progress stream and categorizes the number of times each rule has been
triggered. This will only record whether a lint warning was triggered
and not whether the linter was even used or which rules were present.
That information isn't presently part of the stream.
With this change, we might be reaching some of the limitations that
spying on the progress stream gives us for metrics and may want to
consider another way for the build to communicate metrics back to the
client.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Removes the experimental label from progress metrics. User-metrics
themselves are still experimental so this is still blocked behind the
experimental flag, but this will allow the docker otlp endpoint to
receive these metrics.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This measures the amount of time spent idle during the build. This is
done by collecting the set of task times, determining which sections
contain gaps where no task is running, and aggregating that duration
into a metric.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This measures the duration of exec operations. It does not factor in
whether the operation was cached or not so this should include the
amount of time to determine whether an operation was cached.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This measures the transfer size and duration for image pulls along with
the time spent extracting the image contents.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Measure the transfer size and duration of context transfers for various
categories of local source transfers from the progress stream that's
returned during the build.
Local source transfers are split into one of four categories:
* context
* dockerfile
* dockerignore
* namedcontext
Named contexts that are different names will be categorized under the
same metric.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Without this, we attempt to overwrite the previous display in the lines
above which have been filled with logs from the monitor (see when used
with `--invoke`).
Signed-off-by: Justin Chadwell <me@jedevc.com>
No other parts of the progress rendering modify the inputs, so we should
avoid this as well.
This actually fixes an edge case in pushWithMoby which writes the same
VertexStatus multiple times, modifying the timestamps and similar.
However, if the operation takes long enough the small time difference
can accumulate, and move the Start time far into the past.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This fixes a possible race where messages printed directly after calls
to NewPrinter may appear before the printer starts. With this change, we
delay all of the logs until after.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Refactor the progress printer creation to the caller-side of the
controller api. Then, instead of passing around status channels (and
progressMode strings), we can simply pass around the higher level
interface progress.Writer.
This has a couple of benefits:
- A simplified interface to the controller
- Allows us to correctly extract warnings out of the controller, so that
they can be displayed correctly from the client side.
Some extra work is required to make sure that we can pass a
progress.Printer into the debug monitor. If we want to keep it
persistent, then we need a way to temporarily suspend output from it,
otherwise it will continue printing as the monitor is prompting for
input from the user, and forwarding output from debug containers.
To handle this, we add two methods to the printer, `Pause` and
`Unpause`. `Pause` acts similarly to `Wait`, closing the printer, and
cleanly shutting down the display - however, the printer does not
terminate, and can later be resumed by a call to `Unpause`. This
provides a neater interface to the caller, instead of needing to
continually reconstruct printers for every single time we want to
produce progress output.
Signed-off-by: Justin Chadwell <me@jedevc.com>
The NewPrinter function is mostly borrowed from buildkit. However, at
some point, it seems that the implementations drifted.
This patch updates buildx to be more similar in behavior to it's
buildkit counterpart, specifically, it will explicitly fail if a TTY
output is requested using "--progress=tty", but the output is not
available.
To gracefully fallback to plain progress in this scenario,
"--progress=plain" is required.
Signed-off-by: Justin Chadwell <me@jedevc.com>
As buildkit now uses progress groups for the COPY --link instruction
we need to ensure that we additionally prefix the progress group name,
or the target name will be left off in bake commands with more than one
target.
Signed-off-by: Justin Chadwell <me@jedevc.com>
