| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Send the startup options tagged with their origin so that the server has correct information about the command line as the client received it.
Removes the unconditional stderr printing of all bazelrc startup options in the bazel client. Instead, the startup options are sent to the server and the same informational printing is gated on the --announce_rc option. This avoids unconditional log spam to stderr early in startup. If the server is unreachable or there are errors parsing startup options, the message is still printed to stderr.
Fixes https://github.com/bazelbuild/bazel/issues/2530.
RELNOTES: --announce_rc now controls whether bazelrc startup options are printed to stderr.
PiperOrigin-RevId: 165211007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change ensures that the server process is terminated before the
client process terminates, when evaluating a command that shuts down
the server.
When completing such a command, the server communicates to the client
that the server will terminate itself by setting a termination_expected
bit in the final RunResponse message. The client then waits up to 60s
for the server process to actually terminate. If it does not, then the
client SIGKILLs the server.
Also makes the gRPC server stop accepting new commands before the
shutdown command completes.
Drive-by fix to comments on Search{Un,Null}aryOption.
RELNOTES: Commands that shut down the server (like "shutdown") now ensure that the server process has terminated before the client process terminates.
PiperOrigin-RevId: 161537480
|
| |
|
|
|
|
|
|
|
| |
The user interface is not changing. The policy will still be accepted as a flag passed to the client, as a startup flag (before the command), it will just no longer trigger server restarts and will not be passed on to a bazel server as part of the startup arguments. In batch mode, however, it will still be a startup argument, because the RunRequest proto is not sent, and all invocations restart bazel in batch mode anyway.
Since invocation policy only affects command arguments, and changes in command arguments do not cause server restarts, this is consistent with other server restart behavior.
RELNOTES: Changing --invocation_policy will no longer force a server restart.
PiperOrigin-RevId: 152426207
|
| |
|
|
|
|
|
|
| |
Nothing too detailed, a basic outline.
--
PiperOrigin-RevId: 141205173
MOS_MIGRATED_REVID=141205173
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Made the control flow much simpler and more understandable
- Added some documentation about the interplay of the client and the server
- Abstracted out POSIX mechanisms from blaze.cc so that they can be implemented properly on Windows
- Added assertions that the methods on BlazeServer are called when they should be
Polish for #930.
--
MOS_MIGRATED_REVID=121256601
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
when in gRPC mode.
--
MOS_MIGRATED_REVID=120233121
|
| |
|
|
|
|
|
|
|
|
|
| |
Drive-by fix: eliminate the GRPC messages from the console by passing a null logging function.
This also prepares us for the time when multiple commands will be running, because then we'll need to tell which command exactly we want to interrupt.
Work towards #930.
--
MOS_MIGRATED_REVID=120203008
|
| |
|
|
|
|
|
|
|
| |
C symbols.
Fixed #1155.
--
MOS_MIGRATED_REVID=120107746
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This still has a number of issues, including, but not limited to:
- When switching between gRPC and AF_UNIX mode, you need to do a manual shutdown
- The console is spammed with "connection refused" messages on server startup
- When in gRPC mode, server also starts up an AF_UNIX server even though it's not necessary and concurrent requests probably make Bazel crash and burn
- I have no idea how concurrent gRPC requests are handled and now many threads gRPC creates
- Not tested except under Linux
- The request/response cookies are written in an odd format (negative bytes are not handled correctly). This is only a cosmetic issue, since the data content of the string is the same either way.
Can be tested with the --grpc_port=0 (or a valid port number) startup option.
--
MOS_MIGRATED_REVID=119948959
|
|
|
The code doesn't do anything yet and it's unused code for now. This change only serves to add all the necessary dependencies to BUILD files that gRPC needs.
--
MOS_MIGRATED_REVID=119628697
|
ccalvarin
mschaller
Michajlo Matijkiw
Lukacs Berki