| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
when in gRPC mode.
--
MOS_MIGRATED_REVID=120233121
|
|
|
|
|
|
|
| |
--
Change-Id: I4df7be7de77dd5d44b2090311bce79dbc85a6775
Reviewed-on: https://bazel-review.googlesource.com/#/c/3388
MOS_MIGRATED_REVID=120232900
|
|
|
|
|
|
|
| |
--
Change-Id: I6a2f9026fda578905ccb72b317223eaca16b882b
Reviewed-on: https://bazel-review.googlesource.com/#/c/3440
MOS_MIGRATED_REVID=120228541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also sets the Bazel workspace name to io_bazel_source.
Fixes #848.
Relevant to #1116, #1124,
RELNOTES[INC]: All repositories are now directly under the x.runfiles directory in the runfiles tree (previously, external repositories were at x.runfiles/main-repo/external/other-repo. This simplifies handling remote repository runfiles considerably, but will break existing references to external repository runfiles.
---
Furthermore, if a Bazel project does not provide a workspace name in the WORKSPACE file, Bazel will now default to using __main__ as the workspace name (instead of "", as previously). The repository's runfiles will appear under x.runfiles/__main__/.
--
MOS_MIGRATED_REVID=120224534
|
|
|
|
|
|
|
|
|
| |
packages not in third_party. We don't need to police users' external repositories.
Fixes #1151
--
MOS_MIGRATED_REVID=120222222
|
|
|
|
|
|
|
| |
requirements. Uses this mechanism to configure c/c++ compilation and linking for darwin execution from the crosstool.
--
MOS_MIGRATED_REVID=120218079
|
|
|
|
|
|
|
|
|
|
| |
Second pass.
Consists of adding @Immutable annotations, adding final modifiers, and changing
the types of fields to immutable types.
--
MOS_MIGRATED_REVID=120216592
|
|
|
|
|
|
|
| |
Its old name was confusing because resolve() and getDefault() do radically different things: getDefault() returns a good enough lie for when BuildConfiguration is not available, and resolve() resolves the dependency when we do have a BuildConfiguration.
--
MOS_MIGRATED_REVID=120212630
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
looks like this is probably break []
*** Original change description ***
Bind path to xcrunwrapper in workspace files.
--
MOS_MIGRATED_REVID=120167193
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change disables --java_langtools, --javabuilder_top, --singlejar_top,
--genclass_top, and --ijar_top, and finishes replacing them with
java_toolchain.{javac,javabuilder,singlejar,genclass,ijar}.
RELNOTES: Replace --java_langtools, --javabuilder_top, --singlejar_top,
--genclass_top, and --ijar_top with
java_toolchain.{javac,javabuilder,singlejar,genclass,ijar}
--
MOS_MIGRATED_REVID=120154954
|
|
|
|
|
|
|
| |
target. We also no longer say that the target will not be built because it may well happen during a query, when no building is happening anyway.
--
MOS_MIGRATED_REVID=120130554
|
|
|
|
|
|
|
| |
options classes.
--
MOS_MIGRATED_REVID=120125572
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120124909
|
|
|
|
|
|
|
|
|
|
|
| |
In RecursiveDirectoryTraversalFunction, we must tolerate
NoSuchPackageException being thrown by subdirectories' nodes, since
that can happen in a nokeep_going build.
--
Change-Id: Id9a48256aa209775f27130186c58e03c788d20a9
Reviewed-on: https://bazel-review.googlesource.com/#/c/3392/5
MOS_MIGRATED_REVID=120081575
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
...by only starting the new line, if needed and not already if the last
usable character of the line is written.
--
Change-Id: I86519389fe64fe74ba9045be07483ce5f55d5e9a
Reviewed-on: https://bazel-review.googlesource.com/#/c/3384
MOS_MIGRATED_REVID=119949042
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating output targeted for a specific terminal width, it is
important to know the current position in order to appropriately shorten
the message still to be added to the current line. So make it possible to
add this functionality to the terminal writer itself, to avoid too many
lengthy position computations at call site.
--
Change-Id: I03400b9544c32567fc6ea7ab35e742c4ccd7b610
Reviewed-on: https://bazel-review.googlesource.com/#/c/3373
MOS_MIGRATED_REVID=119946982
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is important for packaging Python code in a way which is compatible
with the way Bazel builds its standard runfiles directory.
Refs #671
--
Change-Id: Ica2adab481cfecabb84b608cd952b0cae5a8653c
Reviewed-on: https://bazel-review.googlesource.com/#/c/2900/
MOS_MIGRATED_REVID=119945845
|
|
|
|
|
|
|
|
|
|
| |
In this way, it can be used for other tests as well. While there, also
unify the two almost identical private LoggingTerminalWriter classes.
--
Change-Id: I9cdf9eb235110a0ad6b9514012a92a923d219b53
Reviewed-on: https://bazel-review.googlesource.com/#/c/3372
MOS_MIGRATED_REVID=119943441
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119942803
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Contributor finds some bugs and after fixing some bugs there are more bugs to fix now.
*** Original change description ***
Mount whole directories into the sandbox when possible
This halves the overhead with sandboxing enabled vs disabled for a test
that basically only mounts a bunch of files out of a directory, and
slows that same test with a single extra file added to the directory
(but not mounted) by only ~4%.
The test is <https://gist.github.com/bsilver8192/10527a862ce16bb7f79a>
with 30000 inputs moved to a subdirectory and on...
***
ROLLBACK_OF=119138157
--
MOS_MIGRATED_REVID=119828267
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the timing assumptions in those tests were quite generous (a sleep
10 should not take 15s, an event supposed to happen every second should
be observed at least once in a 3 second interval), it seems that under
really heavily loaded test environments those assumptions do not hold
true. So remove the tests, as it is better to not have integration tests
for timing properties than to have flaky ones.
--
MOS_MIGRATED_REVID=119826405
|
|
|
|
|
|
|
| |
Remove ArtifactFile, which is rendered obsolete by TreeFileArtifact.
--
MOS_MIGRATED_REVID=119789154
|
|
|
|
|
|
|
|
|
| |
third_party.
I'm confused that Bazel has the concept of third_party, but as long as it does, let's exploit it.
--
MOS_MIGRATED_REVID=119779306
|
|
|
|
|
|
|
| |
rolled back in commit 1250fdac4c7769cfa200af8b4f9b061024356fea. There was nothing wrong with that change.
--
MOS_MIGRATED_REVID=119756383
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119755803
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119653212
|
|
|
|
|
|
|
|
|
| |
--sandbox_debug and --verbose_failures are on. See discussion in #1049.
RELNOTES:
--
MOS_MIGRATED_REVID=119635080
|
|
|
|
|
|
|
| |
and bind().
--
MOS_MIGRATED_REVID=119633865
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119631623
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
--
MOS_MIGRATED_REVID=119625653
|
|
|
|
|
|
|
| |
There's second implementation a few lines below.
--
MOS_MIGRATED_REVID=119618086
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119609967
|
|
|
|
|
|
|
| |
point to the workspace root.
--
MOS_MIGRATED_REVID=119558172
|
|
|
|
|
|
|
|
|
|
| |
The test on the freshness of the timing results depends on the
show_progress_rate_limit; to avoid depending on defaults or rc-files,
set it explicitly on the command line. While there, also move options
before target name.
--
MOS_MIGRATED_REVID=119535250
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Under certain conditions it might happen that simultaenously running
instances of the experimental_ui_test share cached results, leading to
the (deliberatly) slow test taking shorter than tested for. Fix this by
adding the --nochache_test_results options to the test run in the test.
--
MOS_MIGRATED_REVID=119525789
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
The immmediate reason for this change is that we also need to add gRPC support to the proto rules, and we don't want to also support gRPC in a half-baked way.
This makes the Bazel binary much smaller and avoid giving false signals that we (for now) support protobuf compilation. The protobuf rules are only for compiling Bazel itself.
RELNOTES[INC]: Bazel does not embed protocol buffer-related rules anymore.
--
MOS_MIGRATED_REVID=119516246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119351752
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|