| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
PathFragment.TO_PATH_FRAGMENT
RELNOTES: None.
PiperOrigin-RevId: 160668541
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #2679 allowed parentheses ("(" and ")") in globs, but other bracket
style characters were not allowed at the time. It was decided in
issues #2583 and #3048 that other bracket characters should be allowed
as well, since there is no apparent historical reason for disallowing
them in the first place.
Closes #3166.
PiperOrigin-RevId: 159691498
|
|
|
|
|
|
|
|
|
| |
the currently defined hash function for blobs. Some refactoring. Adding an option to set the hash function in the remote worker, defaulting to the current behavior (unfortunately it is a build option, have not found a clean way to specify it at runtime).
BUG=62622420
TESTED=remote worker
RELNOTES: none
PiperOrigin-RevId: 159473116
|
|
|
|
|
|
|
| |
9eea05d068a06ab642dd9d86d46ee5fa2e36b02e.
RELNOTES: n/a
PiperOrigin-RevId: 158988688
|
|
|
|
| |
PiperOrigin-RevId: 157218175
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 154543320
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are now four concrete implementations: RelativeUnixPathFragment, AbsoluteUnixPathFragment, RelativeWindowsPathFragment, AbsoluteWindowsPathFragment.
Goals:
-Reduce memory usage of PathFragment on non-Windows platforms while maintaining existing semantics.
-Make a few simple performance improvements along the way.
-Add TODOs for a few more simple performance improvements.
-Open the way for reducing code complexity of PathFragment. All of the Windows-specific stuff ought not complicate the code so much.
Non goals:
-Make the entire codebase as pretty as possible wrt PathFragment & Windows.
-Make PathFragment usage more sane in general (e.g. change semantics to ban coexistence of Windows and Unix PathFragments).
-Optimize PathFragment as much as possible wrt memory or even in any other dimensions (e.g. gc churn, cpu).
To elaborate, the primary motivation is per-instance memory usage of PathFragment on Unix platforms:
Before this change
------------------
+UseCompressedOops --> 32 bytes per instance
-UseCompressedOops --> 40 bytes per instance
After this change
------------------
+UseCompressedOops --> 24 bytes per instance
-UseCompressedOops --> 32 bytes per instance
Since Bazel can retain lots of PathFragments, the memory savings of this CL are fairly large.
RELNOTES: None
PiperOrigin-RevId: 154052905
|
|
|
|
|
|
|
|
|
| |
latter swallows all filesystem failures, and does not disambiguate missing files from filesystem problems.
The syscall cache now tracks IOExceptions if they are present, just as it does with readdir().
RELNOTES: None
PiperOrigin-RevId: 153185433
|
|
|
|
|
|
|
| |
More info here #2583
Closes #2679.
PiperOrigin-RevId: 152685327
|
|
|
|
| |
PiperOrigin-RevId: 152684266
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 152400979
|
|
|
|
|
|
|
|
|
|
|
|
| |
'create' method.
This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment).
This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations.
RELNOTES: None
PiperOrigin-RevId: 152145768
|
|
|
|
|
|
|
|
| |
allocating a garbage TranslatedPath object.
RELNOTES: None
PiperOrigin-RevId: 152130170
|
|
|
|
|
|
|
|
|
|
| |
This fixes PackagePathLocatorTest.
--
Change-Id: I3d14a80993f6b256acfc732adf2d97b1d2dcb804
Reviewed-on: https://cr.bazel.build/9310
PiperOrigin-RevId: 149634730
MOS_MIGRATED_REVID=149634730
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PathFragment's `equals`, `hashCode`, `compareTo`,
`startsWith`, `endsWith`, and `relativeTo` are now
aware of case-insensitivity when running on
Windows.
This approach is better than
https://bazel-review.googlesource.com/c/9124/
because it preserves path casing, which is
important when computing action output paths.
This change contains two additional bugfixes:
- `compareTo` now takes `driveLetter` into account
- the `InMemoryFileSystem` in `PathWindowsTest` is
not case-insensitive
Fixes https://github.com/bazelbuild/bazel/issues/2613
--
Change-Id: I1a4250a373fff03fa02a6d8360457450b47a42a8
Reviewed-on: https://cr.bazel.build/9126
PiperOrigin-RevId: 149106930
MOS_MIGRATED_REVID=149106930
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 148749485
MOS_MIGRATED_REVID=148749485
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 148625618
MOS_MIGRATED_REVID=148625618
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was previously in unix, but also used from non-unix file systems, which
means it's not actually unix-specific. This is in preparation for splitting
compilation of the unix and windows file systems into separate libraries.
That improves layering and reduces compile times - note that Bazel already
injects the vfs into its lower layers, which should only rely on the normal
vfs APIs, not on anything platform-specific.
--
PiperOrigin-RevId: 147829659
MOS_MIGRATED_REVID=147829659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new CreateJunction in the Windows JNI code
every time we need to create junctions. This means
updating WindowsFileOperations and related tests.
Add test for WindowsFileSystem.createSymbolicLink.
See https://github.com/bazelbuild/bazel/issues/2238
--
Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc
Reviewed-on: https://cr.bazel.build/8896
PiperOrigin-RevId: 147598107
MOS_MIGRATED_REVID=147598107
|
|
|
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/2494
--
Change-Id: I2ca335fa5b3a7759f57085717128912f09363789
Reviewed-on: https://cr.bazel.build/8650
PiperOrigin-RevId: 146761747
MOS_MIGRATED_REVID=146761747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every double-checked lock will be followed up by a regular lock.
Either the children don't exist, in which case we take the lock
twice, or they do exist and we take the lock once.
This makes it so we only ever take the lock once.
I don't know if this makes it faster, but it makes the code
simpler, and shouldn't make it slower.
--
PiperOrigin-RevId: 146553235
MOS_MIGRATED_REVID=146553235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TL;DR: resolve "C:/progra~1" style paths, don't
cache failed resolutions in the parent's
Path.children
When creating WindowsPath objects, resolve the
"C:/progra~1" style paths to "C:/program files".
This enables us to correctly compare paths on
Windows. Without this canonicalization we
incorrectly determine "C:/progra~1" and
"C:/program files" to be different when they are
actually the same.
We only attempt to resolve such paths if the name
looks like it's an abbreviated path.
If resolution fails, probably due to the path not
existing, then we don't cache this Path object in
the parent's `children` list. This avoids stale
cache entries in case the path springs into
existence later in the server's lifetime.
Fixes https://github.com/bazelbuild/bazel/issues/2145
We also need to rectify https://github.com/bazelbuild/bazel/issues/2173
--
PiperOrigin-RevId: 143442134
MOS_MIGRATED_REVID=143442134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also build the JNI library while bootstraping.
This was once submitted in commit 4a249b6962d32ed4cfd4165dfdae4a555b00bb69 but got
rolled back due to some test breakage that's long
since fixed. In this change I'm slightly modifying
the original code in compile.sh.
Using JNI methods however is necessary because we
can't implement WindowsFileOperations.GetLongPath
in native Java, and having that code is a
prerequisite for the fix of https://github.com/bazelbuild/bazel/issues/2145
See also https://github.com/bazelbuild/bazel/issues/2238
--
PiperOrigin-RevId: 142535019
MOS_MIGRATED_REVID=142535019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method converts MSYS paths to Windows path.
It uses the BAZEL_SH envvar to obtain the MSYS
root directory, to which all Unix paths (except
for mounts) are relative.
We cannot handle mounts because we don't want to
read /etc/mtab every time there's a file operation
so we simply apply a heuristic similar to
https://github.com/bazelbuild/bazel/blob/cd4cc09fa6ef96380a3d0888f825dfd1dbada651/src/main/java/com/google/devtools/build/lib/vfs/WindowsFileSystem.java#L52-L63
Also clean up the #ifdefs surrounding SyncFile.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 142531986
MOS_MIGRATED_REVID=142531986
|
|
|
|
|
|
|
|
| |
Fixes #2247.
--
PiperOrigin-RevId: 142143520
MOS_MIGRATED_REVID=142143520
|
|
|
|
|
|
|
|
| |
optional method in FileSystem. Custom FileSystem implementations can
use this to provide their own implementation of glob prefetching.
--
MOS_MIGRATED_REVID=140736304
|
|
|
|
|
|
|
|
|
|
|
| |
that makes an appropriate call to Interners.InternerBuilder#concurrencyLevel.
For current readers of this CL, I used this class everywhere in the Blaze codebase.
For future readers of this CL, this class should be used to create an Interner in the Blaze codebase.
--
MOS_MIGRATED_REVID=140063271
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
refactoring: enabling potential fast digest computation of more than one digest function type.
Usage: bazel --host_jvm_args="-Dbazel.DigestFunction=SHA1" build ...
Ugliness: using a system property (a static non-final variable), because the better way to do it (a flag) would result in a much, much larger refactoring.
More ugliness: I have updated the minimal amount of tests. A lot of tests are still relying on the default value of MD5. Ideally, they need to be updated as well.
--
MOS_MIGRATED_REVID=139490836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change updates WindowsFileSystem so it:
- retrieves the DosFileAttributes instead of the
BasicFileAttributes, because the latter does not
report junctions as directories
- uses just isJunction to decide if a file is a
symlink, doesn't look at whether it's a
directory (again because java.nio.File also
incorrectly reports junctions as
non-directories)
Fixes https://github.com/bazelbuild/bazel/issues/1850
--
MOS_MIGRATED_REVID=138187220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When rewriting stable-status.txt, which happens on each build, avoid updating
the file's ctime and mtime if the new contents match what is already in the
file.
This prevents tickling the TimestampGranularityMonitor for what should be a
no-op update, which in turn could cause null/incremental builds to stall for
up to a second. The problem was magnified on macOS where the default HFS+
file system only has second-level granularity. (This also affects Linux, but
because current Linux file systems have milli/nanosecond-level granularity,
the wait imposed by TimestampGranularityMonitor is minimal and thus not
generally noticeable.)
--
MOS_MIGRATED_REVID=137983794
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PathFragment no longer parses "/c/foo" as "C:/foo"
on Windows, but as a driveletter-less absolute
path. If such a PathFragment is used in creating a
Path object, the WindowsPath.translatePath method
will translate it correctly.
Fixes https://github.com/bazelbuild/bazel/issues/1994
--
MOS_MIGRATED_REVID=137283176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AbstractFileSystem.getFile{Input,Output}Stream
created anonymous File{Input,Output}Stream
objects. These hold a reference to the outer class
instance (AbstractFileSystem). This may prevent
memory release in case the returned objects are
kept around even if the AbstractFileSystem
instance could otherwise be released.
This particular refactoring is unlikely to have
caught any memory leaks like this, so it's not
really necessary, but I came across it and thought
it won't hurt and will future-prove the class
against such leaks.
--
MOS_MIGRATED_REVID=137254192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change rolls forward commit e0d7a540e3c615c628f63fcaaaba0c47fca2cb25 and
commit 8bb4299b28de14eed9d3b57bcaeb9350c81c7db3, and adds a bugfix:
- FileSystem.PathFactory got a new translatePath
method that WindowsFileSystem.PathFactory
overrides to translate absolute Unix paths to
MSYS-relative paths
- Path.getCachedChildPath calls this translatePath
method so the child path is registered with the
correct (translated) parent and under the
correct name (e.g. "C:" instead of say "c")
Below is the rest of the original change
description:
The new subclass WindowsFileSystem.WindowsPath is
aware of Windows drives.
This change:
- introduces a new factory for Path objects so
FileSystems can return a custom implementation
that instantiates filesystem-specific Paths
- implements the WindowsPath subclass of Path that
is aware of Windows drives
- introduces the bazel.windows_unix_root JVM
argument that defines the MSYS root, which
defines the absolute Windows path that is the
root of all Unix paths that Bazel creates (e.g.
"/usr/lib" -> "C:/tools/msys64/usr/lib") except
if the path is of the form "/c/foo" which is
treated as "C:/foo"
- removes all Windows-specific logic from Path
PathFragment is still aware of drive letters and
it has to remain so because it is unaware of file
systems.
WindowsPath restricts the allowed path strings to
absolute Unix paths where the first segment, if
any, is a volume specifier. From now on if Bazel
attempts to create a WindowsPath from an absolute
Unix path, Bazel will make it relative to
WindowsPath.UNIX_ROOT, unless the first component
is a single-letter name (e.g. "/c/foo" which is
"C:/foo").
Subclassing Path is necessary because a Unix-style
absolute path doesn't sufficiently define a full
Windows path, as it may be relative to any drive.
Fixes https://github.com/bazelbuild/bazel/issues/1463
--
MOS_MIGRATED_REVID=137149483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Suspected root cause for Windows bootstrap on Bazel CI breakage:
java.lang.NullPointerException
at com.google.devtools.build.lib.vfs.Path$1.run(Path.java:123)
http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/922/JAVA_VERSION=1.8,PLATFORM_NAME=windows-x86_64/console
*** Original change description ***
VFS: implement a Windows-specific Path subclass
The new subclass WindowsFileSystem.WindowsPath is
aware of Windows drives.
This change:
- introduces a new factory for Path objects so
FileSystems can return a custom implementation
that instantiates filesystem-specific Paths
- implements the WindowsPath subclass of Path that
is aware of Windows drives
- introduces the bazel.windows_unix_root JVM
argument that defines the MSYS root, which
defines the absolute Windows path that is the...
***
--
MOS_MIGRATED_REVID=136583352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Suspected root cause for Windows bootstrap on Bazel CI breakage:
java.lang.NullPointerException
at com.google.devtools.build.lib.vfs.Path$1.run(Path.java:123)
http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/922/JAVA_VERSION=1.8,PLATFORM_NAME=windows-x86_64/console
*** Original change description ***
VFS, WindowsFileSystem: fix UNIX_ROOT retrieval
Executing bash.exe directly instead of through
cmd.exe doesn't seem to work. This change fixes
that problem.
Fixes https://github.com/bazelbuild/bazel/issues/1463 (again)
--
MOS_MIGRATED_REVID=136581532
|
|
|
|
|
|
|
| |
RELNOTES[NEW]: Files now have an "extension" property in Skylark.
--
MOS_MIGRATED_REVID=136425934
|
|
|
|
|
|
|
|
|
|
|
| |
Executing bash.exe directly instead of through
cmd.exe doesn't seem to work. This change fixes
that problem.
Fixes https://github.com/bazelbuild/bazel/issues/1463 (again)
--
MOS_MIGRATED_REVID=136364606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new subclass WindowsFileSystem.WindowsPath is
aware of Windows drives.
This change:
- introduces a new factory for Path objects so
FileSystems can return a custom implementation
that instantiates filesystem-specific Paths
- implements the WindowsPath subclass of Path that
is aware of Windows drives
- introduces the bazel.windows_unix_root JVM
argument that defines the MSYS root, which
defines the absolute Windows path that is the
root of all Unix paths that Bazel creates (e.g.
"/usr/lib" -> "C:/tools/msys64/usr/lib") except
if the path is of the form "/c/foo" which is
treated as "C:/foo"
- removes all Windows-specific logic from Path
PathFragment is still aware of drive letters and
it has to remain so because it is unaware of file
systems.
WindowsPath restricts the allowed path strings to
absolute Unix paths where the first segment, if
any, is a volume specifier. From now on if Bazel
attempts to create a WindowsPath from an absolute
Unix path, Bazel will make it relative to
WindowsPath.UNIX_ROOT, unless the first component
is a single-letter name (e.g. "/c/foo" which is
"C:/foo").
Subclassing Path is necessary because a Unix-style
absolute path doesn't sufficiently define a full
Windows path, as it may be relative to any drive.
Fixes https://github.com/bazelbuild/bazel/issues/1463
--
MOS_MIGRATED_REVID=136350304
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In genrules, cmd strings of the form "$(location :label) ..."
are used with the assumption that the executable named by the
label will be called. This holds true as long as $(location :label)
expands to a string that is recognizable as a path, i.e., as long
as :label does not refer to a file in the top-level directory. In the
latter case, however, that string will be the plain file name and the
shell will search for that name in the search path. This will fail, if
'.' is not in the search path; even worse, if a file with that name
is in the search path before '.', then that one will be called which
is not what the user intended to do. Fix this unintended behavior by
expanding $(location :label) to a string that unambiguously is a path.
--
Change-Id: If8681039a8befae6234fbe0cbe3a0f75eedba7aa
Reviewed-on: https://bazel-review.googlesource.com/#/c/6691
MOS_MIGRATED_REVID=136151500
|
|
|
|
|
|
|
| |
The first legacy glob that a package requires will, if this option is enabled, cause up to that many directories to be eagerly visited by a glob(['**']). The results are thrown away for memory reasons.
--
MOS_MIGRATED_REVID=135148361
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=134005484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
This is causing external_integration_test to fail
See, for example, http://ci.bazel.io/job/bazel-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/236/console:
** test_http_archive_tar_xz ****************************************************
GET /fox.tar.xz HTTP/1.1
User-Agent: Java/1.8.0_101
Host: localhost:36541
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
cat: bazel-out/../external/endangered/fox/male_absolute: No such file or directory
-- Test log: -----------------------------------------------------------
INFO: Reading 'startup' options from /home/ci/.cache/bazel/_bazel_ci/a761298a0949227106f79c62c3bebb6e/bazel-sandbox/81f51af6-eb50-417e-8f8d-b7bba207ee83-661/execroot/linux-x86_64/_tmp/external_integration_test_2/bazelrc: --output_user_root=/home/ci/.cache/bazel/_bazel_ci/a761298a0949227106f79c62c3bebb6e/bazel-sandbox/81f51af6-eb50-417e-8f8d-b7bba207ee83-661/execroot/linux-x86_64/_tmp/external_integration_test_2/root --host_javabase=/home/ci/.cache/bazel/_bazel_ci/a761298a0949227106f79c62c3bebb6e/bazel-sandbox/81f51af6-eb50-417e-8f8d-b7bba207ee83-661/execroot/linux-x86_64/bazel-out/local-fastbuild/bin/src/test/shell/bazel/external_integration_test.runfiles/local_jdk
INFO: $TEST_TMPDIR defined: output root default is '/home/ci/.cache/bazel/_bazel_ci/a761298a0949227106f79c62c3bebb6e/bazel-sandbox/81f51af6-eb50-417e-8f8d-b7bba207ee83-661/execroot/linux-x86_64/_tmp/external_integration_test_2'.
..............................................
____Loading package: zoo
____Loading...
____Loading package: @bazel_tools//tools/cpp
____Loading package: @bazel_tools//tools/jdk
____Loading package: @local_config_xcode//
____Loading package: @local_jdk//
____Loading package: @local_config_cc//
____Loading complete. Analyzing...
____Downloading from [] 0B
____Downloading from [] 1KB
____Loading package: @endangered//fox
____Found 1 target...
____Building...
____[0 / 1] BazelWorkspaceStatusAction stable-status.txt
____[0 / 4] Creating source manifest for //zoo:breeding-program
____[0 / 4] Symlinking //zoo:breeding-program
____[3 / 4] Creating runfiles tree bazel-out/local-fastbuild/bin/zoo/breeding-program.runfiles
____Building complete.
Target //zoo:breeding-program up-to-date:
bazel-bin/zoo/breeding-program
____Elapsed time: 6.903s, Critical Path: 0.04s
____Running command line: bazel-bin/zoo/breeding-program
Fraka-kaka-kaka-kaka-kow
------------------------------------------------------------------------
test_http_archive_tar_xz FAILED: Expected regexp #!/bin/bash
echo Fraka-kaka-kaka-kaka-kow not found in bazel-out/../external/endangered/fox/male_absolute .
/home/ci/.cache/bazel/_bazel_ci/a761298a0949227106f79c62c3bebb6e/bazel-sandbox/81f51af6-eb50-417e-8f8d-b7bba207ee83-661/execroot/linux-x86_64/bazel-out/local-fastbuild/bin/src/test/shell/bazel/external_integration_test.runfiles/io_bazel/src/test/shell/bazel/external_integration_test:154: in call to assert_files_same
/home/ci/.cache/bazel/_bazel_ci/a761298a0949227106f79c62c3bebb6e/bazel-sandbox/81f51af6-eb50-417e-8f8d-b7bba207ee83-661/execroot/linux-x86_64/bazel-out/local-fastbuild/bin/src/test/shell/bazel/external_integration_test.runfiles/io_bazel/src/test/shell/bazel/external_integration_test:150: in call to http_archive_helper
/home/ci/.cache/bazel/_bazel_ci/a761298a0949227106f79c62c3bebb6e/bazel-sandbox/81f51af6-eb50-417e-8f8d-b7bba207ee83-661/execroot/linux-x86_64/bazel-out/local-fastbuild/bin/src/test/shell/bazel/external_integration_test.runfiles/io_bazel/src/test/shell/bazel/external_integration_test:190: in call to test_http_archive_tar_xz
FAILED: test_http_archive_tar_xz
*** Original change description ***
Fixed symbolic link and hard link path not stripped when "strip_prefix" is set.
--
MOS_MIGRATED_REVID=133970692
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=133628392
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=133564429
|
|
|
|
|
|
|
|
| |
TODO: need to stich them all the way through various ActionInputFileCache
implementations!
--
MOS_MIGRATED_REVID=132685408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also add tests for WindowsFileSystem and some for
WindowsFileOperations, so we test both the
JNI-based and Java-native isJunction function, as
well as handling of dangling symlinks/junctions.
Having a Java-native version of this method means
we don't need to use windows_jni.dll for any tests
or for bootstrapping.
This change could help with
https://github.com/bazelbuild/bazel/issues/1735
--
MOS_MIGRATED_REVID=132556440
|
|
|
|
|
|
|
|
|
|
|
| |
This should unbreak the tests, see
https://github.com/bazelbuild/bazel/issues/1735
The tests still break but now due to
https://github.com/bazelbuild/bazel/issues/1736
--
MOS_MIGRATED_REVID=132530222
|
|
|
|
|
|
|
|
|
| |
decompresses tarballs.
Issue link: https://github.com/bazelbuild/bazel/issues/574
--
MOS_MIGRATED_REVID=132434278
|
|
|
|
|
|
|
| |
generating the directory tree nodes efficiently.
--
MOS_MIGRATED_REVID=132433991
|