| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137955061
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137936478
|
|
|
|
|
|
|
| |
This significantly simplifies several of our modules.
--
MOS_MIGRATED_REVID=137713119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Open files cannot be deleted on Windows, thus
`bazel clean --expunge` fails when it attemps to
delete the `command.log` that stdout/stderr is
tee'd into, and so does BlazeCommandDispatcher
when it attemps to delete the `command.log` just
before dispatching to the command implementation
(not just `clean` but any command).
This change:
- closes `command.log` before we attempt to
delete it
- marks CleanCommand (through the Command
annotation) as one that should not write to the
command.log, thus we don't create a new instance
of the file
This change allows `bazel clean --expunge` to
delete everything in the output base, with the
exception of `jvm.log`. Unfortunately that file is
opened by the C++ bazel client process, so we have
to close it there prior to sending the clean to
the bazel server.
See https://github.com/bazelbuild/bazel/issues/1586
--
MOS_MIGRATED_REVID=137278553
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Report the completion of all targets together with the root causes on the build
event stream. To do so, have TargetCompleteEvent and ActionExecutedEvent be
instances of BuildEvent; however, ignore an ActionExecutedEvent in the
BuildEventStreamer if the execution was successful.
By this change we get, for the first time, a build event stream that is naturally
closed, i.e., without Aborted events closing up lose ends. Add a test asserting
this property.
--
Change-Id: Ie90dd52ee80deb0fdabdce1da551935522880a1a
Reviewed-on: https://bazel-review.googlesource.com/#/c/6279
MOS_MIGRATED_REVID=137273002
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137266505
|
|
|
|
|
|
|
| |
nonexistent AF_UNIX mode.
--
MOS_MIGRATED_REVID=137135400
|
|
|
|
|
|
|
|
|
|
|
|
| |
--expunge_async rely on setsid to create a new process group, this is
non-existent on Darwin nor on Windows. This lead to moving the output base
to a location and forget about it silently. Instead, we fall-back to
expunge_async until we completely fixes #1906.
--
Change-Id: Ia932613f687149a85f766de9faa7ce49aaa20b38
Reviewed-on: https://bazel-review.googlesource.com/6694
MOS_MIGRATED_REVID=136340995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new "shutdown on crash" hook to the Blaze modules and call it when we
exit due to a crash. This allows modules to perform necessary cleanup of
internal state when exiting abruptly.
Note that the need for implementing "shutdown on crash" is rare. As an
example of when this may be useful is a module that has spawned background
threads to communicate with a remote server and we want to shut down those
connections in a controlled manner.
--
MOS_MIGRATED_REVID=136330678
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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=136154395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|