[7.1.0] Set the executable bit on files in output directories uploaded to a...
[7.1.0] Set the executable bit on files in output directories uploaded to a disk or remote cache. (#21376) Bazel doesn't preserve executable bits for outputs; all files in the output tree are chmodded to either 0555 or 0755 after action execution, depending on --experimental_writable_outputs. With respect to the disk/remote cache protocol, Bazel always marks uploaded inputs as executable and always ignores the executable bit on downloaded outputs. For uploaded outputs, the behavior currently differs between directories and non-directories; this CL makes the behavior consistent. This makes it more likely that the input Merkle tree to a remote action can hit a cache populated by a previous local action. (See unknown commit where the behavior was changed for non-directory outputs, with the same rationale.) As a minor effect, it also avoids additional I/O to obtain the permission bits from the filesystem, which adds up for very large tree artifacts. PiperOrigin-RevId: 607367059 Change-Id: Ib507a98f32c0a5c89b1ed0f1ec3777f1c6430e28
Showing
- src/main/java/com/google/devtools/build/lib/remote/UploadManifest.java 6 additions, 3 deletions.../com/google/devtools/build/lib/remote/UploadManifest.java
- src/test/java/com/google/devtools/build/lib/remote/GrpcCacheClientTest.java 8 additions, 3 deletions...google/devtools/build/lib/remote/GrpcCacheClientTest.java
- src/test/java/com/google/devtools/build/lib/remote/RemoteExecutionServiceTest.java 64 additions, 20 deletions...devtools/build/lib/remote/RemoteExecutionServiceTest.java
- src/test/java/com/google/devtools/build/lib/remote/UploadManifestTest.java 37 additions, 10 deletions.../google/devtools/build/lib/remote/UploadManifestTest.java
Please register or sign in to comment