| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
As //tools/defaults will be deprecated soon. All usages of //tools/defaults:jdk and //tools/defaults:java_toolchain should be replaced by corresponding targets in //tools/jdk/BUILD package
RELNOTES:none
PiperOrigin-RevId: 202114489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Bazel client on Windows is now 50% faster to
check the embedded tools than it was before.
Results:
- Linux: 20 ms -> 6 ms
- Windows: 294 ms -> 133 ms
Measurements were done with n=10 runs and a hot
server, using blaze::GetMillisecondsMonotonic().
Previously the client performed the same tasks
multiple times while trying to determine if a path
was a good extracted binary. (E.g. converted the
path to Windows format multiple times, checked if
it was a directory twice, opened the path twice.)
Now the client performes these tasks only once,
e.g. it converts path once and stats only once.
See https://github.com/bazelbuild/bazel/issues/5444
Closes #5445.
PiperOrigin-RevId: 201913758
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196272337
|
|
|
|
| |
PiperOrigin-RevId: 196266567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/5157
If a user's default system locale is not `en`, `en_US` or `en_UK`, there may be a chance that `String#toUpperCase` will result in a string that does not exist in the Enum declaration. This is the case in #5157.
To fix this, it's either
1) setting the Locale in the individual `toUpperCase` calls or
2) set Locale to English by default from `Bazel.java`.
I chose the first because it seemed less intrusive, but I'm open to suggestions.
Closes #5184.
PiperOrigin-RevId: 196261078
|
|
|
|
| |
PiperOrigin-RevId: 195040539
|
|
|
|
| |
PiperOrigin-RevId: 193052121
|
|
|
|
|
|
|
|
|
|
| |
The format of Truth's failure messages is about to change, which would break these tests.
Alternatively, I could modify these tests to accept both the old and new Truth message formats, but ideally most tests wouldn't rely on the exact message format at all.
(That suggests that an even better approach might be to just throw an exception whose message is a fixed string. That would avoid relying even on JUnit's message format, unlikely as I think that is to change.)
RELNOTES: None.
PiperOrigin-RevId: 190617095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollforward as requested by the original author @hmemcpy.
*** Original change description ***
Skipping writing FILTERED tests to test.xml
This fixes #3201 by preventing tests that haven't actually run to be written to the test.xml. This is consistent with how e.g. surefire reports work, tests that were filtered out do not appear in the xml.
This allows changing the Bazel plugin in such a way that does not depend on `time` being 0.0.
Closes #4596.
PiperOrigin-RevId: 189610180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently a test class annotated with `@Ignore` will cause the test
runner to fail with
```
Exception in thread "main" java.lang.IllegalArgumentException: Top test must be a suite
at com.google.testing.junit.runner.junit4.JUnit4TestModelBuilder.get(JUnit4TestModelBuilder.java:53)
```
This change treats classes with no tests (either no @Test annotations or
@Ignore at class level) as an empty test suite. The main motivation
behind this is allowing an entire test class to be ignored (e.g. to
quickly deal with a flaky test) without having to modify the BUILD file.
This is desirable in order to reduce the likelihood that a developer
forgets to update the BUILD file when removing the `@Ignore` annotation.
This pull request overrides the previous pull request
https://github.com/bazelbuild/bazel/pull/4073
Closes #4293.
PiperOrigin-RevId: 188850828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollback was requested by original authors @hmemcpy and @ittaiz in #3201:
"We found a problem with this patch... seems that tests that are added dynamically by the test runner (in our case, specs2 'examples' that are generated with Fragments.foreach) do not appear in the xml!"
This should be part of 0.12.0-rc1, otherwise that release will have the above mentioned regression.
*** Original change description ***
Skipping writing FILTERED tests to test.xml
This fixes #3201 by preventing tests that haven't actually run to be written to the test.xml. This is consistent with how e.g. surefire reports work, tests that were filtered out do not appear in the xml.
This allows changing the Bazel plugin in such a way that does not depend on `time` being 0.0.
Closes #4596.
PiperOrigin-RevId: 188455315
|
|
|
|
| |
PiperOrigin-RevId: 185959149
|
|
|
|
|
|
|
|
|
| |
This fixes #3201 by preventing tests that haven't actually run to be written to the test.xml. This is consistent with how e.g. surefire reports work, tests that were filtered out do not appear in the xml.
This allows changing the Bazel plugin in such a way that does not depend on `time` being 0.0.
Closes #4596.
PiperOrigin-RevId: 185810400
|
|
|
|
|
|
|
|
|
|
|
| |
to rules that use the $(JAVA) or the $(JAVABASE) Make variable.
This is necessary because a future Blaze version will require this for rules that use said Make variables. This incompatible change can be tested today by adding the --noexperimental_enable_jvm_configuration_make_variables command line option to Blaze.
This change is part of a large-scale change ([]
RELNOTES: None.
PiperOrigin-RevId: 176834987
|
|
|
|
|
|
|
|
|
| |
This happens when a sh_test has a dependency on a java_binary, so
JACOCO_METADATA_JAR is not set and coverage should not be run on the
java_binary.
RELNOTES: None.
PiperOrigin-RevId: 172881410
|
|
|
|
|
|
|
|
|
| |
as it was not part of a valid junit xml schema.
To cherry-pick for #3286.
RELNOTES: None.
PiperOrigin-RevId: 170022796
|
|
|
|
|
|
|
|
|
|
|
| |
When a timeout occurred, the current test case is interrupted and the others are cancelled. This was not reflected in any way and all tests were reported as success, even if there was a timeout and the tests were cancelled/interrupted.
Also add a status xml attribute to mark if the test was completed, cancelled or interrupted.
Fixes #3763
RELNOTES: None.
PiperOrigin-RevId: 169665622
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
|
|
|
| |
indirectly depend on it by using the $(JAVABASE) or $(JAVA) Make variables.
It was tested by running "bazel build --nobuild" on the affected targest to make sure that they still work.
PiperOrigin-RevId: 166695324
|
|
|
|
|
|
|
|
|
| |
This and further changes may contain minor modifications to BUILD files that
don't serve any apparent purpose. The reason for these changes is that we're
switching from checked-in BUILD files to generated BUILD files, and there may
be small differences between these files.
PiperOrigin-RevId: 166684362
|
|
|
|
| |
PiperOrigin-RevId: 165439218
|
|
|
|
|
|
|
| |
new blaze Java implementation sends the runtime jars encapsulated in a metadata
txt file, instead of listing them in the environment variable. The previous approach led to blaze crashing with an "Argument list too long" error.
PiperOrigin-RevId: 165155269
|
|
|
|
| |
PiperOrigin-RevId: 165003777
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use $(location) to get the unittest.bash script, which allows this test to also
run with a different label prefix. This involves removing the intermediate
testenv.sh script, which doesn't seem to add much value.
We might want to consider a sh_unit_test rule or macro that has an implicit
dependency on the unittest.bash script and doesn't require every test to do
this manually.
PiperOrigin-RevId: 164846477
|
|
|
|
| |
PiperOrigin-RevId: 164252615
|
|
|
|
| |
PiperOrigin-RevId: 163840258
|
|
|
|
|
|
|
|
|
|
| |
Adds back a compiler test empty .cc file. Seems to be an omission in https://github.com/bazelbuild/bazel/commit/65cda4f219e564ccb190b2992151658dfae9904
The _is_gold_supported check in unix_cc_configure.bzl always fails without this change, since the file it's checking with isn't created. Looks like there may be other effects through _add_option_if_supported, although I only noticed because apparently I have written linker-specific code.
Closes #3484.
PiperOrigin-RevId: 163832465
|
|
|
|
|
|
|
|
|
|
| |
After running the new coverage implementation on some real targets I found the following.
1. Inner classes with the same name could be added from different jars. Addressed this by analyzing classes with the same name exactly once.
2. Auto-generated files were added to the coverage report. This is resolved first on the blaze/bazel side by adding to the files with the exec paths of the instrumented files only those that are source files and on the coverage runner side by discarding all the files that are not in that file.
PiperOrigin-RevId: 162478894
|
|
|
|
|
|
|
|
|
|
| |
The new implementation doesn't use one metadata jar for the whole build anymore, but wraps all the uninstrumented classes in each of the build jars, among with a txt file that contains the paths of the files to be instrumented. The paths will be used to output the entire relative filepath to the partial coverage report.
Instead of one metadata jar containing all uninstrumented classes on the runtime classpath, the coverage runner will retrieve all the build jars on the runtime classpath.
Because the build jars contain now both classes and uninstrumented classes, the coverage runner will not analyze the entire given jar, but only the classes in the given jars that have the right suffix.
PiperOrigin-RevId: 161951370
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a minor regression introduced by bazelbuild/bazel@2c3c87fab48646167e4233f539540df6b5ed3d04.
mktemp's interface changed in OS X 10.11 to allow the prefix to be
unspecified, but not specifying the prefix will cause the command to
error out on OS X 10.10 and earlier.
Closes #3281.
PiperOrigin-RevId: 161805877
|
|
|
|
|
|
|
|
|
|
|
| |
We're currently maintaining two sets of BUILD files; one at Google, and one
in the Git repository. We'd like to not do that. This change makes some of
the Bazel BUILD files more closely match their counterparts, in preparation
for removing the internal ones.
Closes #3094.
PiperOrigin-RevId: 158820490
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 157446717
|
|
|
|
|
|
|
| |
The bugs that broke this on Windows ( https://github.com/bazelbuild/bazel/issues/2306 and https://github.com/bazelbuild/bazel/issues/2342 ) have been fixed and FreeBSD has been bootstrapped so we can do this there, too.
RELNOTES: None.
PiperOrigin-RevId: 155371373
|
|
|
|
|
|
|
|
|
| |
deploy jar.
I thought that didn't work for some reason, but I apparently made a mistake while writing the command line.
RELNOTES: None.
PiperOrigin-RevId: 155368830
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/610bf143dd02020e6cd5c94db38ff54c5a504b12 forgot to add them in the tools selection
so we were still building C++ singlejar on Windows MSVC
where we cannot bootstrap it.
PiperOrigin-RevId: 155219067
|
|
|
|
|
|
| |
With MSYS-less version of Bazel for Windows, we have several config settings that correspond to windows, list them all in the select (right now it is breaking our CI: http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/JAVA_VERSION=1.8,PLATFORM_NAME=windows-msvc-x86_64/1477/)
PiperOrigin-RevId: 155211130
|
|
|
|
|
|
|
|
|
| |
through `singlejar --normalize`.
Fixes #2912.
RELNOTES: None.
PiperOrigin-RevId: 155193074
|
|
|
|
|
|
|
| |
Fixes #2848.
RELNOTES: None.
PiperOrigin-RevId: 153692641
|
|
|
|
|
|
|
|
|
| |
It has been disabled in https://github.com/bazelbuild/bazel/commit/bce889840f91f14c05418d960984bcf1a5f59411 and in https://github.com/bazelbuild/bazel/commit/21fb8cac60c36cb527d6131ab0092bcdf138d99a and then was not re-enabled.
Also update src/java_tools/junitrunner/java/com/google/testing/coverage/BUILD to which I accidentally submitted a change directly to our OSS repository.
RELNOTES: None.
PiperOrigin-RevId: 153460778
|
|
|
|
| |
PiperOrigin-RevId: 153444516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears that jarjar is not actually used except for renaming classes
in the coverage collecting Java test runner as verified by
`find . -name BUILD | xargs grep jarjar`
Yak shaving for #2820.
This is necessary because the current version of jarjar does not work
with Java 8 classes because it embeds a version of ASM that doesn't
support that yet.
Change-Id: I6ac59b84bbbc1e85fe8e7f4f4876b98fc6129df0
|
|
|
|
|
|
|
|
|
|
| |
file, so that each test run can have the latest version of the Classpaths.
This does not tackle the case where runfiles are not present, such as windows.
--
PiperOrigin-RevId: 151440999
MOS_MIGRATED_REVID=151440999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classloader. Currently this funcionality is hidden behind the "experimental_testrunner" flag.
Original description (from commit 786cfa2ed980e278c42ee474408844f7e3720385):
Separate the classpaths of the TestRunner with the test target, and use a separate Classloader to load the test target's classes. This enables a clean separation of the classes of the TestRunner with the target under test.
This is achieved with the following steps:
1. Start the test runner with only the bare bones classpaths to the Test Runner's classes which are used by the system ClassLoader.
2. Have all the classpaths required to load the test target's classes in a TEST_TARGET_CLASSPATH environment variable exported by the stub script.
3. Use a new classloader to load all the test target's classes using the paths in TEST_TARGET_CLASSPATH.
This additionally enables the persistent test runner (currently experimental), to reload all the target's classes for every subsequent test run, so it can pick up any changes to the classes in between runs.
The persistent test runner can be used by adding the argument
--test_strategy=experimental_worker to the bazel test command (and having the tag "experimental_testrunner" in the java_test rule).
Tested this against:
1. gerrit/gerrit-common:client_tests: Dismal avg. improvement of 580ms to 557ms (just 23ms)
2. intellij/intellij/base:unit_tests: Somewhat modest avg. improvement 1661ms to 913ms (748 ms)
--
PiperOrigin-RevId: 151065529
MOS_MIGRATED_REVID=151065529
|
|
|
|
|
|
|
|
|
|
|
| |
See https://github.com/bazelbuild/bazel/issues/2725
Related to https://github.com/bazelbuild/bazel/issues/2447
--
Change-Id: I723764ee1b41caf62a7d71abcdcdfb704521f206
Reviewed-on: https://cr.bazel.build/9511
PiperOrigin-RevId: 150882100
MOS_MIGRATED_REVID=150882100
|
|
|
|
|
| |
PiperOrigin-RevId: 150197521
MOS_MIGRATED_REVID=150197521
|
|
|
|
|
|
|
|
| |
This is essentially a rollforward of commit 7d0561b6ca92d72bd8767d4dca50e5437976812c, and changes triggering the perisitent runner using an environment variable instead of argument as suggested in commit 7d0561b6ca92d72bd8767d4dca50e5437976812c
--
PiperOrigin-RevId: 149540564
MOS_MIGRATED_REVID=149540564
|
|
|
|
|
|
|
|
|
|
| |
a testbed of upcoming changes, without breaking existing test targets.
To use the alternate test runner a java test should add the tag "experimental_testrunner" and depend on "@bazel_tools//tools/jdk:ExperimentalTestRunner_deploy.jar" (instead of @bazel_tools//tools/jdk:TestRunner_deploy.jar)
--
PiperOrigin-RevId: 149536298
MOS_MIGRATED_REVID=149536298
|
|
|
|
|
|
|
|
| |
Workaround by adding explicit types for now.
--
PiperOrigin-RevId: 148984433
MOS_MIGRATED_REVID=148984433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks dagger []: []
*** Original change description ***
Separate the classpaths of the TestRunner with the test target, and use a separate Classloader to load the test target's classes. This enables a clean separation of the classes of the TestRunner with the target under test.
This is achieved with the following steps:
1. Start the test runner with only the bare bones classpaths to the Test Runner's classes which are used by the system ClassLoader.
2. Have all the classpaths required to load the test target's classes in a TEST_TARGET_CLASSPATH envi...
***
--
PiperOrigin-RevId: 148405598
MOS_MIGRATED_REVID=148405598
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
separate Classloader to load the test target's classes. This enables a clean separation of the classes of the TestRunner with the target under test.
This is achieved with the following steps:
1. Start the test runner with only the bare bones classpaths to the Test Runner's classes which are used by the system ClassLoader.
2. Have all the classpaths required to load the test target's classes in a TEST_TARGET_CLASSPATH environment variable exported by the stub script.
3. Use a new classloader to load all the test target's classes using the paths in TEST_TARGET_CLASSPATH.
This additionally enables the persistent test runner (currently experimental), to reload all the target's classes for every subsequent test run, so it can pick up any changes to the classes in between runs.
The persistent test runner can be used by adding the argument --test_strategy=experimental_worker to the bazel test command.
Tested this against:
1. gerrit/gerrit-common:client_tests: Dismal avg. improvement of 580ms to 557ms (just 23ms)
2. intellij/intellij/base:unit_tests: Somewhat modest avg. improvement 1661ms to 913ms (748 ms)
RELNOTES: 1) Java tests and suites will now have to explicitly declare JUnit dependency 2) All non-legacy java_tests will now be run in a
--
PiperOrigin-RevId: 148309979
MOS_MIGRATED_REVID=148309979
|