| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
--
MOS_MIGRATED_REVID=118563271
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=118561661
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bazel clean never runs any actions, hence any message
about running actions would confuse the user. Therefore,
signal that clean is a non-building command so that the
experimental UI knows not the report about progress of
building.
--
Change-Id: I193f199b052e990992359bc9efdbe34db397ac5f
Reviewed-on: https://bazel-review.googlesource.com/#/c/3125
MOS_MIGRATED_REVID=118554435
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=118547283
|
|
|
|
|
|
|
|
| |
This is so that we can access the build options during creation, which is a
step towards making the coverage module stateless.
--
MOS_MIGRATED_REVID=118475354
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=118473491
|
|
|
|
|
|
|
| |
This makes the late initialization of BuildView more obviously safe.
--
MOS_MIGRATED_REVID=118469655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As explained in commit 37f3e9ee, after completion of the build, there
is no need any more to update the progress bar. Instead, its last line,
if any, can just float into the scroll-back buffer. From then on, STDOUT
and STDERR events are just passed through. Do so as well for any late
INFO, WARNING, or ERROR events. This will allow avoiding pointless
messages in commands like 'bazel clean' (the patch removing those messages
will also provide an appropriate integration test).
Unfortunately, to make this work properly, we must ensure that both
event handlers get informed about the fact that we have a no-build
command. To do this, we register the event handler with the intended
IO stream on the event bus, as well as a passively observing variant of the
event handler that has direct acces to the full output stream.
--
Change-Id: I148dc0065b6343e4a2a225b2d4fa615b4f720ff5
Reviewed-on: https://bazel-review.googlesource.com/#/c/3124
MOS_MIGRATED_REVID=118444275
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch replaces the usage of hardcoded "Blaze" string by
Constants.PRODUCT_NAME, so when presenting the output to the user
in the open source version, it says "Bazel" instead of "Blaze",
as "Blaze" is the internal name of the tool and "Bazel" the public
one.
Closes #842
--
Change-Id: I2917656d5254fe34b2761d6e2c79deef7c7fb8a5
Reviewed-on: https://bazel-review.googlesource.com/c/3103/
MOS_MIGRATED_REVID=118042541
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will tell the experimental UI not to produce updates on the
build status and also pass through correctly STDOUT/STDERR events.
In particular, the standard output is suitable for consumption by
other tools.
--
Change-Id: Ifffd445433a29df20f062a762fe6280229319196
Reviewed-on: https://bazel-review.googlesource.com/#/c/3123
MOS_MIGRATED_REVID=118024251
|
|
|
|
|
|
|
| |
value 90. When --experimental_oom_more_eagerly is enabled, if after two full GCs the old gen is still >=--experimental_oom_more_eagerly_threshold% full, exit the JVM.
--
MOS_MIGRATED_REVID=117943361
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=117939121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the experimental UI, during build, STDOUT and STDERR events
are reported as separate events, properly terminated by CR LF.
After the completion of the build, however, STDOUT and STDERR
are passed through byte by byte, to allow nicely formatted output.
Info commands, however, do not build, so there is no event to signal
end of build; hence report that fact directly to the UI.
--
Change-Id: Ic236d33ee6e65637016370e15ed37e3d9494a258
Reviewed-on: https://bazel-review.googlesource.com/#/c/3122
MOS_MIGRATED_REVID=117934742
|
|
|
|
|
|
|
|
|
|
|
|
| |
If bazel is invoked with --color=no, two event handlers are in use
simultaneously, using different output streams. For the event bus,
register the one that is aware of ansi control characters, as this
is the one that will also pass through stdout/stderr events.
--
Change-Id: I83f1164b9057cebf9345c315f42c8d54a88d3888
Reviewed-on: https://bazel-review.googlesource.com/#/c/3121
MOS_MIGRATED_REVID=117922780
|
|
|
|
|
|
|
|
| |
This is one of the last pieces of state in BlazeRuntime that isn't safe to
share across command invocations.
--
MOS_MIGRATED_REVID=117910631
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The client provides information about whether the terminal is a tty, and
which width the output should be formatted for. Passing this information
as explicit command-line arguments has the disadvantage that it overrides
any setting in configuration files. While usually there is no one-size-fits-all
value for terminal width, it doesn't make sense either to have an option
where the user cannot set a default. Fix this by providing the client options
as least imported rc-source.
--
Change-Id: Iad9eddbb3ff1777f4b423053e21aeac9fd7c466f
Reviewed-on: https://bazel-review.googlesource.com/#/c/3092
MOS_MIGRATED_REVID=117833645
|
|
|
|
|
|
|
|
|
|
|
| |
When specifying which command names to parse options for, given the
command annotation, ensure that "common" comes first, so that it can
be overridden by more specific options.
--
Change-Id: I20cd90c098e993580c32297d1e36c8a6c939873a
Reviewed-on: https://bazel-review.googlesource.com/#/c/3091
MOS_MIGRATED_REVID=117821257
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=117715554
|
|
|
|
|
|
|
| |
optionally expose a custom factory implementation.
--
MOS_MIGRATED_REVID=117546934
|
|
|
|
|
|
|
|
|
| |
because we halted.
RELNOTES: Tests that failed to build because execution was halted no longer print their status.
--
MOS_MIGRATED_REVID=117542221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One can now invoke native.bazel_version to get the version of Bazel from
the WORKSPACE file.
This can be used to do version check, for instance:
version.bzl:
def check_version(x):
if native.bazel_version < x:
fail("Current Bazel version is {}, expected at least {}".format(native.bazel_version, x))
WORKSPACE:
load("//:version.bzl", "check_bersion")
check_version("0.2")
Fixes #1014.
--
MOS_MIGRATED_REVID=117231557
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=117139503
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
(especially with sharding).
--
MOS_MIGRATED_REVID=116975152
|
|
|
|
|
|
|
| |
OutOfMemoryError and have the JVM send Bazel a SIGUSR2 when it detects an OOM. This should help in certain pathological cases when Bazel GC thrashes for some time after an OOM has been detected.
--
MOS_MIGRATED_REVID=116819359
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=116569594
|
|
|
|
|
|
|
| |
Bazel exit more eagerly due to an OOM will be guarded by this flag.
--
MOS_MIGRATED_REVID=116567102
|
|
|
|
|
|
|
|
|
|
|
|
| |
Events may reach the UI over the event bus simultaneously or
with very small time difference. Updating the UI on the terminal,
however is an expensive operation. So update the UI only once
for simultaneous events.
--
Change-Id: I3e6881f18b37626f6be3ad7b97043b42773812f3
Reviewed-on: https://bazel-review.googlesource.com/#/c/3047
MOS_MIGRATED_REVID=116352143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After completion of the build, there is no need to update the
progress bar any more. Its last line can just move to the scrollback
buffer. The advantage of doing so, is that we then can pass through
STDOUT and STDERR events without additional interference, like line
ending to be sure to know where we position the progress bar and
additional control characters to position the progress bar itself.
In particular, the preformated status report of the tests that were
run will be displayed properly. This makes the experimental UI also
minimally usable for tests.
--
Change-Id: Idaa389b93fc8c9c46c0930f66b4f69b16c3d2e0b
Reviewed-on: https://bazel-review.googlesource.com/#/c/3046
MOS_MIGRATED_REVID=116350626
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Manually break lines in the progress bar (and only in the progress bar!)
that are longer than the terminal width. In this way, we avoid any
confusion about when the terminal advances a line; in particular, when
the terminal is wider than we believe, we do not erase back into the
scrollback buffer.
--
Change-Id: I19f21bdbd6e6af4665d1e712b921f1a15c7d901c
Reviewed-on: https://bazel-review.googlesource.com/#/c/3041
MOS_MIGRATED_REVID=116138487
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=116138214
|
|
|
|
|
|
|
|
|
| |
transformation 'rdeps(<sky_query_environment_universe_scope>, T, depth)' -> 'allrdeps(T, depth)'.
SkyQueryEnvironment can evaluate such allrdeps queries much more efficiently since it doesn't need to bother filtering out targets outside of universe, meaning it doesn't need to have all targets in the universe in memory at the same time.
--
MOS_MIGRATED_REVID=116075008
|
|
|
|
|
|
|
|
|
| |
second time. If the first call is notifying listeners that the command is complete, the second call can overtake it (since it skips notifying listeners) and kill the JVM prematurely.
This change does open up the possibility that the CommandCompleteEvent triggers a hang or blocking process that prevents us from exiting, but I'm not aware of any known cases of that.
--
MOS_MIGRATED_REVID=116053085
|
|
|
|
|
|
|
|
|
| |
...so that it can be used by other event handlers as well.
--
Change-Id: Ic7b37f9041aab63611d05bdb5f18e72bb0c8f1d9
Reviewed-on: https://bazel-review.googlesource.com/#/c/3040
MOS_MIGRATED_REVID=116012068
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to correctly erase the current progress bar, we
need to know how many lines it is long. Instead of trying
to compute it, enforce explicit breaks shorter than the terminal
width.
--
Change-Id: Ifac16b351e1390f553d0ceac2b647b1178b58d0b
Reviewed-on: https://bazel-review.googlesource.com/#/c/3024
MOS_MIGRATED_REVID=115829390
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The handle(Event event) method of the ExperimentalEventHandler does
not produce UI changes for every event observed. Still, it used to
clear and re-add the progress bar unconditionally. Move those operations
into the individual cases that do produce output, so that in the ignored
events nothing is sent to the terminal.
--
Change-Id: I31fd8df0ee2feeb53b6686fe7350848be2a53b6a
Reviewed-on: https://bazel-review.googlesource.com/#/c/3025
MOS_MIGRATED_REVID=115656142
|
|
|
|
|
|
|
| |
Remove the constant.
--
MOS_MIGRATED_REVID=115555161
|
|
|
|
|
|
|
|
|
|
|
| |
While the eventual goal is to improve the reporting of
those events, for the time being, report them as usual,
so that the experimental UI is minimally usable for building.
--
Change-Id: Ib26deaa70feb3be08d0827dbf1012d38e7d28b1c
Reviewed-on: https://bazel-review.googlesource.com/#/c/3017
MOS_MIGRATED_REVID=115551806
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
These events explicitly tell out to produce a well-defined
message on stdout or stderr. Also in the new UI, honor those
requests.
--
Change-Id: I4188c6cb3a2e277b5b805b3d4f4c96c2cdc7b51c
Reviewed-on: https://bazel-review.googlesource.com/#/c/3015
MOS_MIGRATED_REVID=115546439
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Once loading is completed, report this fact. Also report the
number of targets for later reference.
--
Change-Id: Ibffbaa7add9fed48107d8fb320bd2349b1fac503
Reviewed-on: https://bazel-review.googlesource.com/#/c/3012
MOS_MIGRATED_REVID=115533328
|
|
|
|
|
|
|
| |
no[test_]keep_going.
--
MOS_MIGRATED_REVID=115506435
|
|
|
|
|
|
|
| |
--
Change-Id: I68f9f8c897c65b6d51bd21262e25ad6a93ee794f
Reviewed-on: https://bazel-review.googlesource.com/#/c/3011
MOS_MIGRATED_REVID=115454025
|
|
|
|
|
|
|
|
|
|
|
| |
To allow debugging and faster development of the new experimental
UI, add an additional option telling the experimental UI to log
each event available to the handler.
--
Change-Id: Ib14c42d2afa5f52f6c444592274c8eaeeda15a81
Reviewed-on: https://bazel-review.googlesource.com/#/c/3010/2
MOS_MIGRATED_REVID=115453031
|
|
|
|
|
|
|
|
|
|
|
| |
By enabling this option (default is off), a new, still experimental
UI will be used. As it is developped from scratch, this commit simply
implements a UI that does not produce any output at all.
--
Change-Id: I895c0e0744c008212efc7bdfca1457f7907c9b64
Reviewed-on: https://bazel-review.googlesource.com/#/c/3009/
MOS_MIGRATED_REVID=115441032
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=114998075
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the CommandEnvironment to no longer create a LoadingPhaseRunner
eagerly. Unfortunately, that means we can't reuse the TargetPatternEvaluator
either. Fortunately, the SkyframeTargetPatternEvaluator is a very lightweight
class, which only contains the offset as state, so we just create a new
instance whenever we need one.
On the plus side, the LoadingPhaseRunner API is now stateless, and the
QueryCommand no longer creates a unnecessary LoadingPhaseRunner instance.
--
MOS_MIGRATED_REVID=114519731
|