| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
* Refactor Chunker constructor to a builder to reduce constructor overload.
* Pass digest into this where we have it
* Redo ensureInputsPresent to not lose the missing digests during processing so we can pass them to the Chunker constructor.
RELNOTES: None
PiperOrigin-RevId: 207297915
|
| |
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 207137932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows local files referenced by the BEP/BES protocol
to be uploaded to a ByteStream gRPC service.
The ByteStreamUploader is now implicitly also used by the BES
module which has a different lifecycle than the remote module.
We introduce reference counting to ensure that the channel is
closed after its no longer needed. This also fixes a bug where
we currently leak one socket per remote build until the Bazel
server is shut down.
RELNOTES: None
PiperOrigin-RevId: 204275316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces concurrent downloads of action outputs
for remote caching/execution. So far, for an action we would
download one output after the other which isn't as bad as it
sounds as we would typically run dozens or hundreds of actions
in parallel. However, for actions with a lot of outputs or graphs
that allow limited parallelism we expect this change to positively
impact performance.
Note, that with this change the AbstractRemoteActionCache will
attempt to always download all outputs concurrently. The actual
parallelism is controlled by the underlying network transport.
The gRPC transport currently enforces no limits on the concurrent
calls, which should be fine given that all calls are multiplexed
on a single network connection. The HTTP/1.1 transport also
enforces no parallelism by default, but I have added the
--remote_max_connections=INT flag which allows to specify an upper
bound on the number of network connections to be open concurrently.
I have introduced this flag as a defensive mechanism for users
who's environment might enforce an upper bound on the number of open
connections, as with this change its possible for the number of
concurrently open connections to dramatically increase (from
NumParallelActions to NumParallelActions * SumParallelActionOutputs).
A side effect of this change is that it puts the infrastructure
for retries and circuit breaking for the HttpBlobStore in place.
RELNOTES: None
PiperOrigin-RevId: 199005510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a roll-forward of 4465dae23de989f1452e93d0a88ac2a289103dd9, which
was reverted by fa36d2f48965b127e8fd397348d16e991135bfb6. The main difference is
that the new behavior is now gated behind the --noremote_allow_symlink_upload
flag.
https://docs.google.com/document/d/1gnOYszitgrLVet3sQk-TKGqIcpkkDsc6aw-izoo-d64
is a design proposal to support symlinks in the remote cache, which would render
this change moot. I'd like to be able to prevent incorrect cache behavior until
that change is implemented, though.
This fixes https://github.com/bazelbuild/bazel/issues/4840 (again).
Closes #5122.
Change-Id: I2136cfe82c2e1a8a9f5856e12a37d42cabd0e299
PiperOrigin-RevId: 195261827
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
The no-cache tag is not respected (see b/77857812) and thus this breaks remote caching for all projects with symlink outputs.
*** Original change description ***
Only allow regular files and directories spawn outputs to be uploaded to a remote cache.
The remote cache protocol only knows about regular files and
directories. Currently, during action output upload, symlinks are
resolved into regular files. This means cached "executions" of an
action may have different output file types than the original
execution, which can be a footgun. This CL bans symlinks from cachable
spawn outputs and fixes http...
***
PiperOrigin-RevId: 193338629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remote cache.
The remote cache protocol only knows about regular files and
directories. Currently, during action output upload, symlinks are
resolved into regular files. This means cached "executions" of an
action may have different output file types than the original
execution, which can be a footgun. This CL bans symlinks from cachable
spawn outputs and fixes https://github.com/bazelbuild/bazel/issues/4840.
The interface of SpawnCache.CacheHandle.store is refactored:
1. The outputs parameter is removed, since that can be retrieved from the underlying Spawn.
2. It can now throw ExecException in order to fail actions.
Closes #4902.
Change-Id: I0d1d94d48779b970bb5d0840c66a14c189ab0091
PiperOrigin-RevId: 190608852
|
| |
|
|
|
|
|
|
|
|
| |
This provides a io.grpc.ClientInterceptor implementation that can be used to log gRPC call information. The interceptor can select a logging handler to use based on the gRPC method being called (Watch, Execute, Write, etc) to build a LogEntry, which can then be logged after the call has finished. Unit tests for the interceptor are included.
In this change, the interceptor is never invoked, nor are there any handlers implemented for any gRPC methods. The interceptor also never tries to log any entries.
To avoid circular dependency issues (Remote library will depend on logger which depends on remote library for utils), I've factored out the utility classes from the remote library into their own directory/package as part of this change.
PiperOrigin-RevId: 187926516
|
| |
|
|
|
|
|
|
| |
I moved it into DigestUtil preemptively in case we switch to binary instead of hex representation.
TESTED=manually
RELNOTES: None
PiperOrigin-RevId: 185007558
|
| |
|
|
|
|
|
|
| |
This is an important regression, we will want to patch the fix into 0.10
TESTED=fixed unit test, with A/B testing
RELNOTES: Resolved an issue where a failure in the remote cache would not trigger local re-execution of an action.
PiperOrigin-RevId: 184991670
|
| |
|
|
|
|
| |
Add support for directory trees as artifacts. Closes #4011.
PiperOrigin-RevId: 179691001
|
| |
|
|
|
|
|
|
|
| |
- Replace the existing Retrier with Retrier2.
- Rename Retrier2 to Retrier and remove the old Retrier + RetryException
class.
RELNOTES: None.
PiperOrigin-RevId: 177835070
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the FileSystem class to include the hash function as an
instance field. This allows us to have a different hash function
per FileSystem and removes technical debt, as currently that's
somewhat accomplished by a horrible hack that has a static method
to set the hash function for all FileSystem instances.
The FileSystem's default hash function remains MD5.
RELNOTES: None
PiperOrigin-RevId: 177479772
|
| |
|
|
|
|
|
|
| |
This reduces the # of round-trips, improving overall latency, although I didn't profile by how much.
TESTED=with remote execution
RELNOTES: None
PiperOrigin-RevId: 170484009
|
| |
|
|
|
|
| |
TESTED=unit tests
RELNOTES: none
PiperOrigin-RevId: 169395919
|
| |
|
|
|
|
|
|
|
| |
tests fails, we still want to be able to download the logs and other outputs from CAS.
This fixes a bug introduced by https://github.com/bazelbuild/bazel/commit/562fcf9f5dfd14daea718f77da95b43b1400689b. To reproduce: run a failing test vs a BES service, the test log would not be uploaded.
TESTED=unit tests
PiperOrigin-RevId: 169143428
|
| |
|
|
|
|
| |
Update the callers that only need getMetadata to use the new interface.
PiperOrigin-RevId: 167992239
|
| |
|
|
|
|
| |
Use ByteStream for uploads.
PiperOrigin-RevId: 166844266
|
| |
|
|
|
|
|
|
|
|
|
| |
BES and Remote Execution have separate implementations of gRPC channel
creation, authentication and TLS. We should merge them, to avoid
duplication and bugs. One such bug is #3640, where the BES code had a
different implementation for Google Application Default Credentials.
RELNOTES: The Build Event Service (BES) client now properly supports
Google Applicaton Default Credentials.
PiperOrigin-RevId: 164253879
|
| |
|
|
|
|
|
|
|
|
| |
If a remote download fails, delete any output files that might have
already been created. Else, this might intefere with a subsequent
locally executed actions that expects none of its output files to
exist. See #3452.
Change-Id: I467a97d05606c586aa257326213940a37dad9dd5
PiperOrigin-RevId: 163336093
|
| |
|
|
|
|
|
|
| |
Also added tests specifically for the output, to ensure we don't break it again.
TESTED=remote worker, unit tests
RELNOTES: fixes #3380
PiperOrigin-RevId: 163283558
|
| |
|
|
|
|
|
|
|
| |
success.
This can happen per spec, if multiple builds try to upload the same blob concurrently.
Also, added this to the RemoteWorker, per spec.
PiperOrigin-RevId: 162647548
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
#3379
Commit dc24004873c335 broke the upload of locally executed action
results. Also, update our unit tests who did not catch this error.
P.S.: olaola@ is the author of this change, but due to time constraints
we had to merge it while she was asleep.
Change-Id: Ib150152c0bddc8311908c105aef208506d3b6a8d
PiperOrigin-RevId: 161954553
|
| |
|
|
|
|
|
|
|
|
| |
- Only pass to the GrpcRemoteExecutor constructor the objects it really
needs.
- Share a Retrier between GrpcRemoteCache and GrpcRemoteExecutor.
RELNOTES: None
PiperOrigin-RevId: 161660054
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove the Chunker.Builder and use the Chunker constructors instead.
- Fix a correctness bug, where the chunker would ignore the return value
of InputStream.read(byte[]).
- Have Chunk.getData() return a ByteString as opposed to a byte[]. All
callsides need ByteString objects and this change makes the subsequent
change possible.
- Have the Chunker use a preallocated byte[] in order to avoid
allocating a new one on every call to next().
RELNOTES: None.
PiperOrigin-RevId: 161637158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current ByteStream upload implementation has no support for application-level
flow control, which resulted in excessive buffering and OOM errors.
The new implementation respects gRPCs flow control.
Additionally, this code adds support for multiple uploads of the same
digest. That is, if a digest (i.e. file) is uploaded several times
concurrently, only one upload will be performed.
RELNOTES: None.
PiperOrigin-RevId: 161287337
|
| |
|
|
|
|
|
| |
This helped me find a bug in a rewrite of the remote worker, which is
independent of this change.
PiperOrigin-RevId: 161204914
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make the RemoteSpawnRunner match RemoteSpawnStrategy functionality, including
local fallback, remote caching, and execution. This is done so we can
actually finish the migration to the SpawnRunner API, for which I've had a
pending change for several months now.
- Never throw StatusRuntimeException from the GrpcRemoteCache or the
GrpcExecutor. We almost never do, since the Retrier catches them implcitly,
so a number of catch blocks were already unreachable. Carefully document
the cases where we still need to handle it.
- RemoteSpawnStrategy / RemoteSpawnRunner no longer catch gRPC-specific
exceptions; they should be able to handle any reasonable remote caching /
execution implementation (except we don't have a common interface for
GrpcRemoteExecutor yet), with no dependency on gRPC as such. Note that the
RemoteSpawnStrategy class will actually go away after the SpawnRunner
migration (eventually).
- However, ensure that we _are_ actually throwing CacheNotFoundException;
the retrier implicitly catches that also, so we need to manually unwrap
from RetryException.
- Don't call into the EventHandler from RemoteSpawnStrategy; instead, throw
an exception with the message, and let the higher levels handle the
reporting (we only allow this for exception + local fallback, for which
there's no good reporting API right now).
PiperOrigin-RevId: 161195666
|
| |
|
|
|
|
| |
than per-call.
PiperOrigin-RevId: 160892006
|
|
|
PiperOrigin-RevId: 160872755
|
tomlu
buchgr
Benjamin Peterson
Googler
olaola
Hadrien Chauvin
ulfjack