| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For an action, whenever the status or strategy changes, reset
the timer. In this way, we show the time an action spent in the
current state, rather than the total time the action spent since
started. This might give a better picture of what is currently
going on in the system.
Fixes #4089.
Change-Id: I441337cf2eec58702889ac7a6a9ed150708e8c9d
PiperOrigin-RevId: 176497486
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When showing the current actions, the most interesting are those
that are currently being executed, not those that are waiting for
resources or otherwise in the process of being scheduled. Therefore,
show the executing actions at the top of the list. Also add more
visual hints to distinguish executing from non executing actions.
Screenshot
(14:51:21) [160 / 230] 32 actions, 11 running
Compiling lotsofwork/true986.c; 0s linux-sandbox
Compiling lotsofwork/true982.c; 0s linux-sandbox
Compiling lotsofwork/true983.c; 0s linux-sandbox
Executing genrule //lotsofwork:true975_c; 0s linux-sandbox
Compiling lotsofwork/true981.c; 0s linux-sandbox
Linking lotsofwork/true_999; 0s linux-sandbox
Linking lotsofwork/true_996; 0s linux-sandbox
Linking lotsofwork/true_998; 0s linux-sandbox
Compiling lotsofwork/true980.c; 0s linux-sandbox
Compiling lotsofwork/true98.c; 0s linux-sandbox
Executing genrule //lotsofwork:true974_c; 0s linux-sandbox
[Sched] Creating runfiles tree bazel-out/k8-fastbuild/bin/lotsofwork/true_974.runfiles
[Sched] Linking lotsofwork/true_997
[Sched] Linking lotsofwork/true_995
[Sched] Linking lotsofwork/true_99
[Sched] Linking lotsofwork/true_991 ...
Improves on #4089.
Change-Id: I1bc6636d5e53a16151023bba595e38259eb1ac88
PiperOrigin-RevId: 176483192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if an action is planned to run and a strategy assigned,
it does not mean it is actually executing; e.g., it might be
waiting for local resources. To reduce confusion, show the
status instead of the execution strategy for non-executing
actions. Also avoid the word "running" for the total number
of executing and scheduled to be executed actions.
Improves on Issue #4089.
Change-Id: If658c1a24ee26eb27ccd892847af18015355a8d3
PiperOrigin-RevId: 175818071
|
|
|
|
|
|
|
| |
"blaze test".
RELNOTES: None.
PiperOrigin-RevId: 174386473
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For commands that do not send a BuildFinishedEvent, we normally use the
NoBuildEvent to determine the end of the build and hence the moment
where the UI should not any more interfere with the output. For some
requests, like fetch, however, we should continue to report progress
till the very end (as there is no output to interfere with). Do so,
and also be sure that the experimental UI also reports downloads if
not explicitly in a loading or analysis phase.
While there, also group digits in the number of downloaded bytes, to
increase readability.
Change-Id: I31efeee5bdb1d29b2ecf842acb3e383e297707f8
PiperOrigin-RevId: 161935456
|
|
|
|
|
|
|
|
|
|
| |
As the state tracker keeps track of which transports we still have to
wait for, make the event handler just ask the state tracker. In this way,
we also handle gracefully if the closing of a transport is reported more
than once.
Change-Id: I0e1959d827268319ec00541994314c9325ef2307
PiperOrigin-RevId: 157395608
|
|
|
|
|
|
|
|
| |
We initially didn't consider that multiple BuildEventStreamer instances might
exist during a build.
RELNOTES: None.
PiperOrigin-RevId: 157385069
|
|
|
|
|
|
|
|
|
|
| |
Move the position of the timestamp to the beginning of the line to
have a more readable log. Also, show the timestamp for progress as
well. While there, reduce timestamp to second precision, to reduce
noise.
Change-Id: Ibfa6caca2e0d207f54e3660bccbf894bba3c5ae3
PiperOrigin-RevId: 155181731
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollforward with fix for test flakiness. BEP transport closed
events are delivered via their own threadpool and thus might
not have been sent immediately. BuildEventStreamerTest#testSimpleStream
now waits for a bit until the event has been delivered. I ran the test
with --runs_per_test=1000 several times and had no further failures.
*** Original change description ***
Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082.
*** Reason for rollback ***
Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000.
RELNOTES: None
PiperOrigin-RevId: 154170833
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000.
RELNOTES: None
PiperOrigin-RevId: 154090559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BEP (build event protocol) upload may at times take longer than the build
itself. This is especially true for cached builds, where there is little build
work, but the protocol still needs to be uploaded. In this case the bazel UI
will now display that it's waiting for BEP upload, both in the current and the
new experimental UI (--experimental_ui).
When executing a run command, blaze waits for the BEP upload to finish before
it runs the target.
Major Modifications:
- The BuildEventTransport interface now also has a name() method that returns
a string. When waiting for a transport to finish the BEP upload, this string
is displayed in the UI.
- The BuildEventStreamer now emits two new events
AnnounceBuildEventTransportsEvent and BuildEventTransportClosed on the event
bus. This is how the experimental UI is informed about BEP upload progress.
RELNOTES: None
PiperOrigin-RevId: 154052401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--noexperimental_enable_critical_path_profiling flags are all specified, then Bazel will delete Actions from ActionLookupValues as they are executed in order to save memory.
Because an already-run action may output an artifact that is only requested later in the build, we need to maintain a way for the artifact to look up the action. But in most cases we don't need to keep the action itself, just its output metadata.
Some actions unfortunately are needed post-execution, and so we special-case them.
Also includes dependency change with description:
Move action out of key. This keeps action references from polluting the graph -- actions are just stored in one SkyValue, instead of being present in SkyKeys.
This does mean additional memory used: we have a separate ActionLookupData object per Action executed. That may reach ~24M for million-action builds.
PiperOrigin-RevId: 151756383
|
|
|
|
|
|
|
|
|
|
|
| |
In this way, we can easily add other fetch-like events to be reported
in a similar way as plain downloads.
--
Change-Id: I518df5ba27b6593eca98d30407b582f509a52aeb
Reviewed-on: https://cr.bazel.build/9313
PiperOrigin-RevId: 149655918
MOS_MIGRATED_REVID=149655918
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the experimental UI, to be able to report appropriately about ongoing
downloads, we need to track their state, as updated by the DownloadProgressEvents.
Do so. Also report on ongoing downloads in the progress bar.
--
Change-Id: I668e963cd6da85ec598b23724066d366d465271f
Reviewed-on: https://cr.bazel.build/9114
PiperOrigin-RevId: 148899297
MOS_MIGRATED_REVID=148899297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When requested to produce a suffix of a string of a string
of a given length, gracefully handle the case where the requested
length is negative---simply return the empty string in
this case. While there, mark this static method as such; also
increase visibility to default as it is generally useful and
should be tested as an interface of this class.
--
Change-Id: I821966f7ba3828809bc6d000358803c131740ec9
Reviewed-on: https://bazel-review.googlesource.com/#/c/4223
MOS_MIGRATED_REVID=129080284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if a build completes with tests failing, the final status
message is "INFO: Build completed successfully, xxx actions". While
technically correct, it might mislead the user to believing all tests
have passed (especially when only looking at the status in the terminal
title). Therefore, if a build completes with failing tests, mention the
number of failed tests in the final status message.
--
Change-Id: I9234fbfdf2ad43dd29af660966dde73bf0c9311a
Reviewed-on: https://bazel-review.googlesource.com/#/c/3918
MOS_MIGRATED_REVID=126176452
|
|
|
|
|
|
|
|
|
|
|
| |
In the experimental UI, also support the --show_timestamps option
which asks that for each event a timestamp be added to the the
output. Fixes #1436.
--
Change-Id: I8f9db958525edfbca12ed2c1f1396f25f865b897
Reviewed-on: https://bazel-review.googlesource.com/#/c/3916
MOS_MIGRATED_REVID=126165328
|
|
|
|
|
|
|
|
|
|
|
|
| |
When writing the experimental state tracker is asked to produce a progress
bar, it can be requested to have a one-line version. This one is used, e.g.,
if curses are not available and therefore it cannot be erased. Also honor
that request, if reporting about loading progress.
--
Change-Id: Ice3045fc86280e420b789a94b03427ff578f4a11
Reviewed-on: https://bazel-review.googlesource.com/#/c/3912
MOS_MIGRATED_REVID=126057511
|
|
|
|
|
|
|
| |
--
Change-Id: I1b8acc9dbd73ede3952a51f3f67b32e1b7e536a2
Reviewed-on: https://bazel-review.googlesource.com/#/c/3900
MOS_MIGRATED_REVID=125957281
|
|
|
|
|
|
|
|
|
|
|
|
| |
The experimental UI shows the oldest still running actions as well
as the total number of running actions. However, just presenting
them as "X actions" is confusing for some users; so be more explicit
and mention them as "X actions running".
--
Change-Id: I26b8450690dc8b233271596d3c85e9c0924f7333
Reviewed-on: https://bazel-review.googlesource.com/#/c/3901
MOS_MIGRATED_REVID=125941605
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the end of the analysis phase, show the amount of work done during
this phase (e.g., number of packages loaded) in a way similar to the
last progress message shown for loading. In this way, users will over
time learn the number of packages their project depends on; thus the
progress shown during loading will become more meaningful to them.
--
Change-Id: If56fab5704c419be988e55f0c1705b3732c11369
Reviewed-on: https://bazel-review.googlesource.com/#/c/3872
MOS_MIGRATED_REVID=125656896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the experimental UI always shows the 3 oldest, still running actions.
While this seems a reasonable default, some users requested to be able to change
the number of actions shown. Hence replace the hard-coded value by a flag.
While there, also fix an off-by-one error in deciding when to put the ellipsis
symbol.
--
Change-Id: I037d208360fa1d3f100c99ab1ab1f5fc140138ac
Reviewed-on: https://bazel-review.googlesource.com/#/c/3811
MOS_MIGRATED_REVID=125427168
|
|
|
|
|
|
|
|
|
|
| |
In the experimental UI, for the running actions also report their strategy.
This will give a more complete picture of what Bazel is currently doing.
--
Change-Id: I9553c952ed494e0db225b2a1ae5e8eba00f68617
Reviewed-on: https://bazel-review.googlesource.com/#/c/3820
MOS_MIGRATED_REVID=125162808
|
|
|
|
|
|
|
|
|
|
|
| |
The experimental UI also keeps track, in the progress bar, of the last test
that completed. When using curses, use colors to indicate whether the test
passed or not.
--
Change-Id: Iaa01a773c3bbf534692ed21dd420596cb63e2585
Reviewed-on: https://bazel-review.googlesource.com/#/c/3752
MOS_MIGRATED_REVID=123871492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To give a better understanding of which packages are on the critical
path during loading and analysis, provide information in the same way
as during execution: show the earliest started, but not yet completed
package. As not all packages looked at during the analysis phase are
reported to the progress receiver, use a custom class to aggregate those
data.
--
Change-Id: I03c25efdecb4124e1bc06fce8be9175dc56b5500
Reviewed-on: https://bazel-review.googlesource.com/#/c/3700
MOS_MIGRATED_REVID=123408689
|
|
|
|
|
|
|
|
|
|
|
| |
When reporting about actions that are still running, groups those belonging
to the same test. In this way, more useful information can be presented in the
progress bar, instead of wasting a whole line for a single shard.
--
Change-Id: Id1f5a0595767906d6a75f6533be54f3c262ddd67
Reviewed-on: https://bazel-review.googlesource.com/#/c/3646
MOS_MIGRATED_REVID=123097744
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a progress message has to be shortened, as it does not fit in a
line in the progress bar, add a new first attempt: if the message the
path implicit to the label, only shorten that path within the message
(if that gets short enough, leaving a reasonable part of the path);
usually, the additional information is more useful than having a longer
part of the path present.
While there, also fix incorrect length computation in a different case
of message shortening.
--
Change-Id: Ied80e03cace1b249fc0f4e11bce41f2b4207b6ad
Reviewed-on: https://bazel-review.googlesource.com/#/c/3670
MOS_MIGRATED_REVID=122818198
|
|
|
|
|
|
|
|
|
|
|
| |
After the initial loading phase, further packages are loaded during
analysis. Show in the experimental UI the total number of packages
loaded during analysis phase to indicate at least some progress.
--
Change-Id: I345c6f806591e70e4397fc3e3365718dde95d7d2
Reviewed-on: https://bazel-review.googlesource.com/#/c/3645
MOS_MIGRATED_REVID=122728719
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the progress bar of the experimental state tracker, when
reporting that precisely one target is being analyzed, show
that target. While there, also consistently switch to American
spelling.
--
Change-Id: Ib9027145aed69e757a7caf7076abdeb1c5ebeb30
Reviewed-on: https://bazel-review.googlesource.com/#/c/3583
MOS_MIGRATED_REVID=121833343
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optionally support a target width for the experimental state tracker;
if given, it will try to produce a status bar with lines shorter than
that limit, if possible, so that the status bar does not have to be
broken.
--
Change-Id: Ic5843285300ec10cf3e21b9b7402a6557f6bdb5e
Reviewed-on: https://bazel-review.googlesource.com/#/c/3374
MOS_MIGRATED_REVID=119954289
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the experimental UI, show the most recent finished test in the (long) progress bar.
For failed test, immediately write an entry to the scroll-back buffer. In this
way, the user can get an already investigate test failures while other tests are
still running.
--
Change-Id: I5df29dc55b979c8547e99e9ac3f60563736b48e8
Reviewed-on: https://bazel-review.googlesource.com/#/c/3351
MOS_MIGRATED_REVID=119732631
|
|
|
|
|
|
|
|
|
|
|
| |
When running tests, a useful information to know is the number of tests
that have passed and failed already. Hence subscribe to the relevant events
and provide this information in the progress bar as well.
--
Change-Id: I6fabec3f4585500f096b820dbbd5e8e6897647fa
Reviewed-on: https://bazel-review.googlesource.com/#/c/3350
MOS_MIGRATED_REVID=119727962
|
|
|
|
|
|
|
|
|
|
|
|
| |
When bazel is used without curses, every status message ever written
will never be deleted and, instead, stick in the log. To keep the output
manageable in this case, provide a one-line progress bar to be used in
this case.
--
Change-Id: Ia0f9619d406e676f88ff536617a56fd4990cb51e
Reviewed-on: https://bazel-review.googlesource.com/#/c/3294
MOS_MIGRATED_REVID=119520912
|
|
|
|
|
|
|
|
|
|
|
|
| |
When showing the earliest started actions in the progress
bar of the experimental UI, it is a wasted line to use a whole
line just to show dots indicating that more actions are running;
instead, just put the dots on the same line as the last action.
--
Change-Id: I37fcb654f689786ab522036b563409b15b85437f
Reviewed-on: https://bazel-review.googlesource.com/#/c/3290
MOS_MIGRATED_REVID=119439830
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subscribe to the LoadingPhaseStartedEvent to get the LoadingProgressReceiver;
use it to provide information about the loading progress. As this event will not
be raised by the LegacyLoadingPhaseRunner, do not depend on this event and still
produce a sensible status bar if it is never raised.
--
Change-Id: I1db24ceaf7de4fc42d00b02f470066cb38c877b4
Reviewed-on: https://bazel-review.googlesource.com/#/c/3270
MOS_MIGRATED_REVID=119261675
|
|
|
|
|
|
|
|
|
|
|
| |
In the experimental UI, use progress events as an occasion to
update the progress bar. However, to avoid unnecessary noise, only
do so, if the progress bar potentially changes with time.
--
Change-Id: I9bee093c29e0eb50e7fcce2fa6e941a02d615def
Reviewed-on: https://bazel-review.googlesource.com/#/c/3206
MOS_MIGRATED_REVID=118944208
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the progress bar shows the 3 earliest started still running actions.
While this might give some indication about which actions delay the build process,
it lacks quantitative information about how long the delay is. By adding the current
run time to the progress bar, at least some quantitative information is provided.
--
Change-Id: Ib90eda67d87384a4372cda7779a09a44cea2b8dd
Reviewed-on: https://bazel-review.googlesource.com/#/c/3205
MOS_MIGRATED_REVID=118933973
|
|
|
|
|
|
|
|
|
|
| |
In this way, the ExperimentalStateTracker has access to all the information needed
to provide information about the run-time of currently running actions.
--
Change-Id: I0f4e48f39e9ebe63555e4bb1d70df2a6dbb65430
Reviewed-on: https://bazel-review.googlesource.com/#/c/3204
MOS_MIGRATED_REVID=118929758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the experimental UI has the first properties we want to keep
in the long run, add a test asserting the following semantic
properties.
- Whenever only one action is running, it is shown somehow in the
progress bar.
- Completed actions should not be shown in the progress bar.
- The earliest-started still running action should be visible in
the progress bar.
While there, also drop the assumption in the ExperimentalStateTracker
that the ExecutionProgressReceiverAvailableEvent has to come before
any actions that has not been finished yet.
--
Change-Id: Ica52eb12546703e4f8f9d9c64928208621d19ced
Reviewed-on: https://bazel-review.googlesource.com/#/c/3048
MOS_MIGRATED_REVID=117121300
|
|
|
|
|
|
|
|
|
|
|
|
| |
By not only having a unique identifier for each running action, but
also remembering additional information about the actions, in particular
the action itself, we can provide a more meaningful description of
the currently running actions in the progress bar.
--
Change-Id: I34760a437bf731f057162ca4d08368fe35d4bc71
Reviewed-on: https://bazel-review.googlesource.com/#/c/3045
MOS_MIGRATED_REVID=116349484
|
|
|
|
|
|
|
|
|
|
| |
To improve reporting, in particular about the actions to carry out,
make use of the ExecutionProgressReceiver.
--
Change-Id: I9295199e4c6d9626a193b48b8f332ab2af8e3014
Reviewed-on: https://bazel-review.googlesource.com/#/c/3044
MOS_MIGRATED_REVID=116347930
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subscribe to start and completion events of actions to keep track
of which actions are currently running. In the progress bar show
up to 3 actions currently running, giving preference to the ones
that started the most early. Also keep track of completion of
analysis and build.
--
Change-Id: I9183a84821abca85e2331baa059e1f636d756caf
Reviewed-on: https://bazel-review.googlesource.com/#/c/3016
MOS_MIGRATED_REVID=115549337
|
|
Add a state tracking class that is capable of keeping track of
the internal state of the computation. Use it to provide a status
bar at the lower end of the terminal.
--
Change-Id: I39c17a80a238b3bc0d94527652b56a793f580d02
Reviewed-on: https://bazel-review.googlesource.com/#/c/3014
MOS_MIGRATED_REVID=115538418
|