| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Causes our integration tests on Darwin to time out
*** Original change description ***
Make --watchfs a common command option.
Adding an options parameter to DiffAwareness#getCurrentView seems like the
simplest way to achieve that.
Alternatives considered:
1. Making the diff awareness modules stateful. However, I did not want to do so
as I've also been working on improving the module API to reduce state, or at
least to have a proper lifecycle management for any necessary state.
2. Making the watchFs flag a constructor parameter. However, that would also
invalidate any implement...
***
--
MOS_MIGRATED_REVID=136070807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding an options parameter to DiffAwareness#getCurrentView seems like the
simplest way to achieve that.
Alternatives considered:
1. Making the diff awareness modules stateful. However, I did not want to do so
as I've also been working on improving the module API to reduce state, or at
least to have a proper lifecycle management for any necessary state.
2. Making the watchFs flag a constructor parameter. However, that would also
invalidate any implementations that don't use the flag (of which we have
several).
3. Only passing in a single boolean flag instead of an options class provider;
however, this is a more principled, futureproof API, which allows other
modules / awareness implementations to use their own options.
RELNOTES: --watchfs is now a command option; the startup option of the same
name is deprecated. I.e., use bazel build --watchfs, not blaze --watchfs
build.
--
MOS_MIGRATED_REVID=136026835
|
|
|
|
|
|
|
|
|
|
|
| |
...so that it gets informed about all relevant events happening
during the build. For the time being, we only consider one transport,
that to a text file.
--
Change-Id: I429c957f39a07b795a71acbeaa1360178574a1d1
Reviewed-on: https://bazel-review.googlesource.com/#/c/6276
MOS_MIGRATED_REVID=135464059
|
|
|
|
|
|
|
|
|
| |
the Bazel server.
RELNOTES[INC]: --command_port=-1 to use AF_UNIX for client/server communications is not supported anymore.
--
MOS_MIGRATED_REVID=135355673
|
|
|
|
|
|
|
|
|
| |
...to produce 'build --action_env=' statements, not common ones. See also d59bcb633.
--
Change-Id: Ib0fc75ff8991650c43dd72300b3d92a6986b1165
Reviewed-on: https://bazel-review.googlesource.com/#/c/6493
MOS_MIGRATED_REVID=135350639
|
|
|
|
|
|
|
| |
Ideally, stdout would be line buffered, too, except that we sometimes pump large amounts of binary data through it, so line buffering would result in performance loss.
--
MOS_MIGRATED_REVID=135237450
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step on a journey toward allowing commands to AbruptExit
wherever they please, similar to how the user can press Ctrl+C at any time
and we (should) bail out as fast as we can.
By interrupting the command's main thread, we at least offer the command
the ability to see that an error requiring a bail has happened, and it should
trigger at potentially more locations, rather than just between phases.
--
MOS_MIGRATED_REVID=135152330
|
|
|
|
|
|
|
| |
overrides. Also, have AbstractBlazeQueryEnvironment#evaluateQuery take an OutputFormatterCallback instance rather than a Callback instance. This is more sensible since the latter is only intended to be used intra-query, while the former is intended for usage in end-to-end query evaluation. This lets us slightly simplify QueryCommand, by shifting the responsibility for managing the OutputFormatterCallback to AbstractBlazeQueryEnvironment#evaluateQuery.
--
MOS_MIGRATED_REVID=134827588
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BuildEventStreamer will listen for BuildEvents and stream them
to the provided transports. It also ensures events are properly chained:
for unsolicited events, it will add progress events to chain them and
at the end of a build it closes all announced but not produced events
as aborted.
--
Change-Id: I623b582657573fe1288821c96f084e0ab0bca4d4
Reviewed-on: https://bazel-review.googlesource.com/#/c/6275
MOS_MIGRATED_REVID=134787541
|
|
|
|
|
|
|
|
| |
Usually an OutputStream will do. Forgo the extra layer of indirection and
stream directly to the output.
--
MOS_MIGRATED_REVID=134682243
|
|
|
|
|
|
|
|
|
|
|
| |
Instead have SkyQueryEnvironment#evaluateQuery be responsible for handling cleanup of its internal ForkJoinPool.
In addition to being a more sensible way of organizing the code (imo, it makes sense for SkyQueryEnvironment to clean up after itself), this fixes several issues:
(i) If query evaluation is interrupted, the AbstractBlazeQueryEnvironment#close call at the end of the try-with-resources statement in QueryCommand would be blocking and non-urgent. N.B. This was not an issue with the current ForkJoinPool usage, but was an issue with the old ThreadPoolExecutor usage.
(ii) Because of how the code in QueryCommand was structured, OutputFormatterCallback#close would happen _before_ the AbstractBlazeQueryEnvironment#close call. If query evaluation is interrupted, threads executing query tasks may be invoking the callback after the callback had been shut down!
--
MOS_MIGRATED_REVID=134573395
|
|
|
|
|
|
|
|
|
| |
action sees a different shared action that is in the midst of being an action cache hit.
Concretely, suppose that the user builds A, then requests C and D. C depends on A, D depends on B, which is a shared action with A. If B executes at just the right time, as C is finishing execution, C can think that it must add itself to B's execution path, which is incorrect.
--
MOS_MIGRATED_REVID=134475095
|
|
|
|
|
|
|
|
|
| |
#getShellExecutable() method.
That's all it was used for anyway.
--
MOS_MIGRATED_REVID=133824769
|
|
|
|
|
|
|
| |
callback for streaming a precomputed result.
--
MOS_MIGRATED_REVID=133720742
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add 'bazel info client-env' which outputs entries for the configuration
file that would freeze the current client environment. The main intended use case
is to use 'bazel info client-env >> .bazelrc' to keep the project reproducible
once a suitable value for the environment variables that used to be taken from the
client environment has been found.
--
Change-Id: Ib4d14dd824d223f335a4d4de04ee21c4a3ec4d83
Reviewed-on: https://bazel-review.googlesource.com/#/c/6112
MOS_MIGRATED_REVID=133699234
|
|
|
|
|
|
|
|
| |
Sometimes, especially in the case of a lot of output, one may not want to write
everything twice.
--
MOS_MIGRATED_REVID=133388416
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=133257532
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=133248078
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...to determine which actions have to be recomputed based on changes
to the client environment. Note that this change does it the simple way
and reconsideres all actions on a changed client environment, while still
only reexecuting those, where the part that was inherited from the environment
actually did change.
--
Change-Id: Ie1116d094642165e5e959447a6fcf49d19b37d6e
Reviewed-on: https://bazel-review.googlesource.com/#/c/5431
MOS_MIGRATED_REVID=133010705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
evaluation:
-Rename QueryExpression#evalConcurrently to QueryExpression#parEval. (parallelism is not concurrency! See https://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/)
-Have SkyQueryEnvironment#eval (used recursively in #evaluateQuery) dynamically call QueryExpression#parEval when appropriate.
-Delete QueryExpression#canEvalConcurrently.
-Add ThreadSafety annotations in a bunch of relevant places in the query codebase.
-A bunch of testing infrastructure to test parallel query evaluation.
-TODOs for implementing parallel evaluation of all QueryExpression nodes.
--
MOS_MIGRATED_REVID=132436340
|
|
|
|
|
|
|
|
|
| |
Previously, it was possible for us to edit the options in command.editOptions,
after reporting them to the modules, though I don't have any examples of that
happening. I found this just looking through the code.
--
MOS_MIGRATED_REVID=132310873
|
|
|
|
|
|
|
|
|
|
| |
History in
https://github.com/emacs-mirror/emacs/blo[]f125aa3de06fa0180a83ec7b5a26970309eeeb6/etc/NEWS#L1769-L1773
RELNOTES: Emacs' [C-x `], a.k.a. next-error, works again in emacsen >= 25.1
--
MOS_MIGRATED_REVID=131851164
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=131569674
|
|
|
|
|
|
|
| |
Initialize these from BlazeModule.serverInit instead of on-the-fly.
--
MOS_MIGRATED_REVID=131564738
|
|
|
|
|
|
|
|
|
|
|
| |
As the execution of an action now also depends on the client environment,
make the latter part of the ActionExecutionContext, so that enough context
is provided to actually execute an action.
--
Change-Id: Ida7bf407ef0c0375728faba92494bfd47dcbaeb8
Reviewed-on: https://bazel-review.googlesource.com/#/c/5391
MOS_MIGRATED_REVID=131377490
|
|
|
|
|
|
|
| |
file systems).
--
MOS_MIGRATED_REVID=131280794
|
|
|
|
|
|
|
| |
rolling our own in ExperimentalEventHandler.
--
MOS_MIGRATED_REVID=130935928
|
|
|
|
| |
MOS_MIGRATED_REVID=130747105
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=130742362
|
|
|
|
|
|
|
| |
Also allow AbruptExitException from all server startup hooks.
--
MOS_MIGRATED_REVID=130513167
|
|
|
|
|
|
|
| |
The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer.
--
MOS_MIGRATED_REVID=130327770
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, Bazel generates a new UUID for every build invocation. In some
use cases, however, the invocation of Bazel is part of a larger build
process or otherwise controlled by a different tool. In this case, it
is useful to tell Bazel the identifier of the build to make it fit with
other identifiers generated by the controlling process. To achieve this,
the variable BAZEL_INTERNAL_INVOCATION_ID from the client environment
is inspected and if it is set and its value is a syntactically correct
UUID, this UUID will be used as the identifier for the build. It is in
the responsibility of the caller to ensure the id is sufficiently unique
if that environment variable is set.
--
MOS_MIGRATED_REVID=130079446
|
|
|
|
|
|
|
|
|
| |
the logical rollback of commit 67ad82a319ff8959e69e774e7c15d3af904ec23d.
RELNOTES[INC]: Bazel supports Unix domain sockets for communication between its client and server again, temporarily, while we diagnose a memory leak.
--
MOS_MIGRATED_REVID=130027009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't do anything yet, it's in preparation for the execroot rearranging
change. The execroot will have one bazel-out per repo, so it'll look like:
execroot/
repo1/
bazel-out/
local-fastbuild/
bin/
repo2/
bazel-out/
local-fastbuild/
bin/
genfiles/
repo3/
bazel-out/
local-fastbuild/
testlogs/
and so on. Thus, any output path (getBinDirectory() & friends) needs to know
what the repo name is. This changes so many places in the code I thought it
would be good to do separately, then just flip the functionality in the
execroot-rearranging commit.
While I was poking around, I changed all of the refs I could from getPackageRelativeArtifact() to getBin/GenfilesArtifact(), so that 1) rule implementation don't have to know as much about roots and 2) they'll be more isolated from other output dir changes.
`bazel info` and similar just return roots for the main repository.
The only "change" is passing around a target label in the Java rules.
Continues work on #1262.
--
MOS_MIGRATED_REVID=129985336
|
|
|
|
|
|
|
| |
This is safer; newInstance on class objects bypasses exception checking.
--
MOS_MIGRATED_REVID=129976805
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=129863453
|
|
|
|
|
|
|
|
| |
It's never used, and it's tricky to run with multiple different file systems
in the same process -> remove it to simplify.
--
MOS_MIGRATED_REVID=129858142
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=129856323
|
|
|
|
|
|
|
| |
This allows us to make the coverage module stateless if it depends on options.
--
MOS_MIGRATED_REVID=129852270
|
|
|
|
|
|
|
|
| |
Closes #1496.
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/1496
MOS_MIGRATED_REVID=129846158
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=129843837
|
|
|
|
|
|
|
| |
Require all callers to call initWorkspace after BlazeRuntime construction.
--
MOS_MIGRATED_REVID=129842292
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done in preparation for allowing multiple workspaces / commands in a
single server. That requires changes to the module API, which currently
hard-codes a 1:1 correspondence between workspaces and servers. Note how
BlazeDirectories exists even when it runs outside a workspace.
It's not ideal that the output base is in ServerDirectories, and the
BlazeRuntime creation also still requires a BlazeDirectories instance.
--
MOS_MIGRATED_REVID=129736613
|
|
|
|
|
|
|
|
|
| |
another command.
This is kind of lame (better would be to guarantee that once a command is accepted, it will run), but better than just crashing.
--
MOS_MIGRATED_REVID=129606325
|
|
|
|
|
|
|
| |
--
Change-Id: Id1f37cfe4dcb77a4af0465028f6b17e574b85954
Reviewed-on: https://bazel-review.googlesource.com/#/c/4191/
MOS_MIGRATED_REVID=129442887
|
|
|
|
|
|
|
|
|
| |
It has been superseded by gRPC.
RELNOTES[INC]: Blaze doesn't support Unix domain sockets for communication between its client and server anymore. Therefore, the --command_port command line argument doesn't accept -1 as a valid value anymore.
--
MOS_MIGRATED_REVID=129424092
|
|
|
|
|
|
|
| |
on Windows by default)
--
MOS_MIGRATED_REVID=129319018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...to in particular never own a lock while waiting for the
update thread to finish. This avoids a deadlock when the update
thread tries to enter the synchronized part of doRefresh while
the thread trying to stop the update thread holds the lock.
Also renable experimental_ui_test now that the race condition leading
to the deadlock is fixed. The absence of flakiness has been verified
by running the test locally 100 times. Fixes #1560.
--
Change-Id: I5d85b347e6cb7a1da8d5a724d6f9cd7461e33e5b
Reviewed-on: https://bazel-review.googlesource.com/#/c/4225
MOS_MIGRATED_REVID=129079398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Break the situation where an update thread tries to start another
update thread early, by telling the doRefresh method when it is
called from within an update thread. While no second thread would be
started in this case anyway (as the global variables indicate that
a thread is already in existence), a lock is still required for this
step, which can cause all kinds of problems. Note that we don't have
to worry about the update thread being about to be stopped in that moment,
as only global events indicating completion stop the update thread.
--
Change-Id: Ib025ba2b12bcd339c590593213eeedfd9cb230d3
Reviewed-on: https://bazel-review.googlesource.com/#/c/4224
MOS_MIGRATED_REVID=129077891
|