| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If tests are run with --test_output=streamed, output has to be passed through
before the end of the (overall) build. In this situation, enforcing a line-end
to redraw the status bar messes up the output that is streamed through. Therefore,
buffer stdout/stderr to full lines and pass them through without extra newlines
added.
--
Change-Id: I52d5dfbd1cb30a6ce2d7d2fd34658a606abcc277
Reviewed-on: https://bazel-review.googlesource.com/#/c/3620
MOS_MIGRATED_REVID=122248012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rollback of commit cda4b4eae0c495a8f90f2a70a8db46e34062ee26.
*** Reason for rollback ***
Roll-forward with fixes (see ExternalPackageBuilder).
*** Original change description ***
Automated [] rollback of commit 178a3dfda8bf72abf22758597a90a4afb8eed181.
*** Reason for rollback ***
Broke ci.bazel.io.
See #1234.
*** Original change description ***
Allow modules to inject a custom AttributeContainer.
--
MOS_MIGRATED_REVID=122100417
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=121996611
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=121960458
|
|
|
|
|
|
|
|
|
| |
message.
This fixes the output "Executed 1 out of 1 tests".
--
MOS_MIGRATED_REVID=121949576
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
...use Constants.PRODUCT_NAME instead. Fixes #1244.
--
Change-Id: Icdf07c5e0cdadc0e459708f13dae78f70b5ef026
Reviewed-on: https://bazel-review.googlesource.com/#/c/3580
MOS_MIGRATED_REVID=121819053
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke ci.bazel.io.
See #1234.
*** Original change description ***
Allow modules to inject a custom AttributeContainer.
--
MOS_MIGRATED_REVID=121658474
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=121497233
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some had incorrect words, or were missing a word and the end period.
Make it match with the descriptions in CommonCommandOptions.java.
Add a short documentation comment to |restart_reason| field.
--
Change-Id: Iac802eb3ed4f72dfd402e85d2098a5616b40a9de
Reviewed-on: https://bazel-review.googlesource.com/3530
MOS_MIGRATED_REVID=121478703
|
|
|
|
|
|
|
|
|
| |
InfoItems can
now take parameters.
--
MOS_MIGRATED_REVID=121379097
|
|
|
|
|
|
|
|
|
| |
These attributes are going away imminently.
select() is the new abi_deps.
--
MOS_MIGRATED_REVID=121294764
|
|
|
|
|
|
|
|
|
|
|
| |
command to see if a flag policy applies, check whether the flag applies by seeing if its list of commands matches one of the commands in the hierarchy.
This avoids the tedious and brittle specification of all commands that may use a flag, while providing better filtering out of inapplicable flags.
RELNOTES: A FlagPolicy specified via the --invocation_policy flag will now match the current command if any of its commands matches any of the commands the current command inherits from, as opposed to just the current command.
--
MOS_MIGRATED_REVID=121159131
|
|
|
|
|
|
|
|
|
|
|
| |
assumed-to-be-immutable filesystem type of output_base.
When we do have an OutputService, defer computation of the OutputService's dynamic filesystem type until we actually need it at the start of a "build" or "test" command.
This saves ~450us on each invocation, according to my benchmarks.
--
MOS_MIGRATED_REVID=121156323
|
|
|
|
|
|
|
|
|
| |
This saves the cost of (1) collecting all Options classes and (2) getting all their @Option annotations. Note that there is no savings on reflection costs, since that's already memoized internally by OptionsParser.
This saves ~250us per Blaze invocation.
--
MOS_MIGRATED_REVID=121153156
|
|
|
|
|
|
|
|
|
| |
BlazeRuntime#getDefaultsPackageContent is called.
Thanks to nharmata for the suggestion.
--
MOS_MIGRATED_REVID=120984951
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120962924
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2009!).
If a "blaze clean --expunge" was run concurrently with another command (that was waiting for the lock), it's possible that the clean command deletes the lock file, the new server starts up, then the JVM shutdown hooks delete the PID files from the *new* server.
There is still a slight possibility of a race condition if the lock is deleted then IOException occurs which prevents the BlazeShutdownException from being raised, but I'd rather not introduce another channel from command implementations to RPCServer to close that loophole.
This issue was triggered by commit 5a78166ee4edbd295f5d5fdb94785025285e764b, after which the PID files for the new server are written a bit more early, thus increasing the time window in which the race condition can happen.
--
MOS_MIGRATED_REVID=120805163
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120699557
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, do not own a lock while waiting for another
thread---especially not the update thread that might be waiting
for the very lock were holding.
--
Change-Id: I46aef3585b712e25cd4317004eacd8b48557a341
Reviewed-on: https://bazel-review.googlesource.com/#/c/3462
MOS_MIGRATED_REVID=120686232
|
|
|
|
|
|
|
|
|
|
|
| |
In particular:
- Make a SIGINT to the server interrupt every command
- Parse negative numbers on the command line correctly (std::stoi throws an exception, and I'd rather not start using C++ exceptions)
- Use "bytes" for command line arguments instead of "string" in the client/server proto . This is more principled, although we pretend all arguments are strings all over the place and it works for "blaze run" mostly by accident.
--
MOS_MIGRATED_REVID=120434432
|
|
|
|
|
|
|
|
|
| |
- Actually make it work again (commit 00cfb7df61b1f3d9fac8ee29d92b315cbfe6d28f broke it, maybe I shouldn't send out changes in a hurry next time)
- Rename --grpc_port to --command_port (it's a bit better name)
- Do not send a kill signal to the server that can't be connected if we only connect to it to verify its presence
--
MOS_MIGRATED_REVID=120418784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
This is a roll-forward of commit 044adedc70de040475443e52eb1a3c692159790e
--
MOS_MIGRATED_REVID=120338148
|
|
|
|
|
|
|
|
|
|
|
|
| |
With remote repositories, it is useful to do this to execute an input
file which isn't actually part of the source tree.
Closes #984
--
Change-Id: Ic986ea9bbe88e0edb933939ce1d7a8b6ea9d6e88
Reviewed-on: https://bazel-review.googlesource.com/#/c/3030/
MOS_MIGRATED_REVID=120248102
|
|
|
|
|
|
|
| |
when in gRPC mode.
--
MOS_MIGRATED_REVID=120233121
|
|
|
|
|
|
|
|
|
|
|
|
| |
The version command is not expected to every run any actions.
Hence any messages about progress of the build process or running
actions would be confusing. Therefore, signal this fact to allow
the experimental UI to present information accordingly.
--
Change-Id: I8a75704a39e161f52c4d008677f62e4b36097647
Reviewed-on: https://bazel-review.googlesource.com/#/c/3387
MOS_MIGRATED_REVID=120203058
|
|
|
|
|
|
|
| |
Work towards #930. With this, it's conceivable that server mode works on Windows to some degree (I haven't tried, though, because there are many issues that need to be fixed)
--
MOS_MIGRATED_REVID=120202037
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120111522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reporting a multi-line test-failure message (the test that failed,
plus the paths to the log files) to the scrollback buffer, it makes sense
to end this whole block by an empty line. If, however, the test failure
does not report any logs (e.g., if the build was interrupted), the next
scroll-back buffer line can follow immediately to keep the scroll-back
buffer more compact.
--
Change-Id: I59d8ba9416d0a9bcbc8d959fee21cc94fa89018e
Reviewed-on: https://bazel-review.googlesource.com/#/c/3386
MOS_MIGRATED_REVID=120108504
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
The BlazeDirectories are also needed for loading the WORKSPACE file, so inject
them as part of preparePackageLoading rather than in createConfigurations,
which is too late.
--
MOS_MIGRATED_REVID=119931633
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119868282
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the presence of server/grpc_port does not guarantee that the server actually listens to it and we can't guarantee it, either, because it can always be kill -9'd.
I haven't decided yet how the transition between AF_UNIX and gRPC will work. For now, I'm happy that we can start up a Java server.
The way to get the kernel-chosen port is truly awful, but it is apparently impossible to do so in a different way:
https://github.com/grpc/grpc-java/issues/72
--
MOS_MIGRATED_REVID=119828354
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever an event has to be reported to the scroll-back buffer, the old progress
bar has to be removed first. Afterwards, it is redrawn. In a setting without
cursor control, this, however, litters the log with lots status bars. Therefore,
only redraw the progress bar after an event if cursor control is available. Note
that the refresh thread will eventually ensure an up-to-date progress bar anyway.
--
MOS_MIGRATED_REVID=119737382
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
The last version of the status bar will drop into the scroll-back
buffer. Hence it should really represent the final state. To achieve
this, ignore the refresh limit on the progress bar for its final update.
--
Change-Id: I50b327dca80c12c9373e59a8702063369b18c461
Reviewed-on: https://bazel-review.googlesource.com/#/c/3333
MOS_MIGRATED_REVID=119637626
|
|
|
|
|
|
|
|
| |
As part of that, move a BinTools and the WorkspaceStatusActionFactory to the
BlazeWorkspace.
--
MOS_MIGRATED_REVID=119633702
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the experimental UI should be usable in all situations, we also have
to care about the situation where updating the status bar in place is not
possible. In this case, we have to make sure we do not litter the output
to much. To achieve this,
- we use the short one-line version of the status bar, and
- reduce the frequency for time-based updates.
Unfortunately, this means that we have to further complicate the timing mechanisms
for updating the progress bar. We now have 3 time intervals in place:
- a short one, after which we update the progress bar, if we dropped an update
due to too frequent events,
- an intermediate one, describing the frequency of status bar updates due to time passing, and
- a long one for purely time-based updates of the progress bar if we cannot update it in place.
--
Change-Id: I5d59ba174c4d290b07181620e238362a8d21a6eb
Reviewed-on: https://bazel-review.googlesource.com/#/c/3295
MOS_MIGRATED_REVID=119527089
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the experimental UI honor the --show_progress_rate_limit flag.
While just dropping a status bar update if it happens too soon after
the last update shown would be easy, there are a few delecate points
to keep in mind.
Assume that several updates happen after another and then nothing for
a long time. Then the last(!) update is the one the user wants to see,
as it most accurately reflects which actions are running during the
long period. However, the simple dropping algorithms would show the
first of those state updates. So, whenever we refrain from updating due
to the rate limit we to make sure that an update will happen soon-ish,
even if no events are reported for a long time.
We do this by having (at most) one thread that periodically triggers
updates of the progress, if the rate limit allows this. This mechanism
is additionally used to ensure that the progress bar, when showing
time-dependent data is kept fresh. For this property we also add a test.
There is a third point to keep in mind: users (and also our tests) want
to see all phases. However, some phases (like loading) might be so short
that they happen in its entirety within a refresh interval. Therefore,
whenever a new important phase starts, we skip the rate limit interval
once; note that this happens at most a fixed number of times during the
entire build.
--
Change-Id: Iee68194d7eb92d6ef9efdc7abde6f56edfa21ce8
Reviewed-on: https://bazel-review.googlesource.com/#/c/3293
MOS_MIGRATED_REVID=119515272
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lines are wrapped in the progress bar to reliably know how many
lines we'll eventually have to erase (there are a couple of reasons
for this; for example, the information about the terminal width often
is unreliable). So, if we don't erase lines anyway, we can as well let
the terminal break lines.
--
Change-Id: Id20806e6d53bfeccc781200eeac96acf48a74b1d
Reviewed-on: https://bazel-review.googlesource.com/#/c/3292
MOS_MIGRATED_REVID=119510906
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel can be asked to uses colors, but not to use other curses options.
In this case, the ExperimentalEventHandler cannot rely on the terminal
to ignore all curses output; hence it has to actively refrain from using
curses that move the cursor.
--
Change-Id: I026edade4366a8c5a8e56d376e8a4603f5c73b92
Reviewed-on: https://bazel-review.googlesource.com/#/c/3291
MOS_MIGRATED_REVID=119439855
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
IOExceptions and so we need to check if any were encountered.
--
MOS_MIGRATED_REVID=119417412
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a less specific option specification in a rc file could override a more specific option specification when there's a non-trivial Command hierarchy. A concrete example would be a "build --foo=1" line overriding a "test --foo=2" line for a "test" invocation.
See the added test for more details.
Also fix some typos in BlazeCommandDispatcherRcoptionsTest.java.
Note that commit dc0fbb42ab22ab8f3205b0884069e1ffe03677c9 was rolled back in commit 417dad0f1e0d0ed4ccd5f8e52b49eb79937da49d which also incidentally rolled back commit 4f0fbe1b09333806cce76b75214e98c7684766e0. So this change is effectively a roll-forward of both of those, plus the bug fix, plus the typo fixes, and plus a documentation update.
--
MOS_MIGRATED_REVID=119276218
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Changed the semantics of local .blazerc handling, requiring a Blaze release rollback ([]).
*** Original change description ***
Make specific options win over common ones
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.
--
MOS_MIGRATED_REVID=119227260
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119051781
|
|
|
|
|
|
|
|
|
|
|
| |
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
|