| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
| |
This is possibly a nit, but we don't want to reuse flag names in the future, so it's a good idea to include what the flag *does* in the name as opposed to just the feature it affects, in case the same feature is changed multiple times. Updated javadoc for incompatible change system to say so.
This rename is ok because these flags have only been submitted over the past couple days.
RELNOTES: None
PiperOrigin-RevId: 155371363
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, silently ignore them in the same way we do for rules to which
aspects are not applicable.
In the future aspects will gain the ability to apply to, and propagate
through, files.
RELNOTES: None.
PiperOrigin-RevId: 155369925
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
There's no need to check for the OS version, as we can just try to use
sandbox-exec and if it works, we're good.
Change-Id: I7fe9a0b55856c646da915a2872531f050a25b110
PiperOrigin-RevId: 155368707
|
|
|
|
|
|
|
|
|
|
| |
In preparation to support multi-configuration builds, provide infrastructure
allowing build events to reference BuildConfigurations. The streaming mechanism
will ensure that build configurations are introduced in the stream before being
referenced for the first time.
Change-Id: I6b96fbebc76a05eff4f75a07e8a9cfbcd57f9c22
PiperOrigin-RevId: 155368666
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(fallback only).
On macOS the processwrapper-sandbox will be used when the darwin-sandbox doesn't
work. Most notably this is the case for nested sandboxing, e.g. Bazel running
Bazel inside an integration test.
Also includes a fix to pull in some extra environment vars on macOS, similar to
what DarwinSandboxedStrategy and StandaloneSpawnStrategy already do. Without
this the processwrapper-sandbox seems to occasionally cause ObjC builds (and two
of our tests) to fail.
Change-Id: Ic7462080caf56d9bb98e2f3765bd37853b01632b
RELNOTES: Sandboxing is now enabled by default on FreeBSD (via processwrapper-sandbox).
PiperOrigin-RevId: 155366728
|
|
|
|
|
| |
Change-Id: I1355c2448cb6cbbcdbace81051a7beb8659f1f00
PiperOrigin-RevId: 155366727
|
|
|
|
|
|
|
| |
Build on CentOS was failing because of missing macros, see http://ci.bazel.io/job/bazel-docker-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=docker/557/console.
Change-Id: I1b7b2ef2b1f26d4dac5439f4fcd01e2ef6553dcf
PiperOrigin-RevId: 155365288
|
|
|
|
|
| |
Change-Id: I43dfd979aee0c510ec18b479f2a6bd55562b3fc0
PiperOrigin-RevId: 155361450
|
|
|
|
|
| |
Change-Id: I68797947905166b71a58d8332be18fc7bd6de30d
PiperOrigin-RevId: 155360327
|
|
|
|
|
|
|
| |
Closes #2959.
Ping #2692 for cherry-picking into Bazel 0.5.0.
PiperOrigin-RevId: 155357560
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 is not a valid port number and thus do not mean "no gRPC command server".
If you try to pass -1 to command_port you get:
$ bazel --command_port=-1 build //...
Invalid argument to --command_port: '-1'.
Must be a valid port number or 0.
Change-Id: I6c17167f6a285b21fcd064cea8bdc7e6770ac984
PiperOrigin-RevId: 155352835
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 155321388
|
|
|
|
|
|
|
|
|
|
|
|
| |
the general collection interface (e.g. List) with an immutable type (e.g. ImmutableList).
For constant field declarations, you should use the immutable type (such as ImmutableList) instead of the general collection interface type (such as List). This communicates to your callers important semantic guarantees ([]
For more info, see:[]
Cleanup change automatically generated by error-prone refactoring //third_party/java_src/error_prone/project/core/src/main/java/com/google/errorprone/bugpatterns:MutableConstantField_refactoring on targets //third_party/bazel/...
PiperOrigin-RevId: 155305768
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 155293316
|
|
|
|
| |
PiperOrigin-RevId: 155287620
|
|
|
|
|
|
|
| |
AndroidDataSerializerAndDeserializerTest.
RELNOTES: None
PiperOrigin-RevId: 155268496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Results in NegativeArraySizeExceptions when there's a high volume of data.
*** Original change description ***
BEP: Report stdout/stderr
By recording registering a properly synchronized OutErr as listener
and providing it as OutErrProvider to the BuildEventStreamer.
Change-Id: Id553fcdb85327be28561634268511304fcc2ad3f
PiperOrigin-RevId: 155252872
|
|
|
|
|
|
|
|
|
|
| |
mark compilations of test code.
We plan to use this for Error Prone checks that need to distinguish
between test and production code, such as enforcing
@VisibleForTesting.
PiperOrigin-RevId: 155231021
|
|
|
|
| |
PiperOrigin-RevId: 155223937
|
|
|
|
| |
PiperOrigin-RevId: 155223580
|
|
|
|
|
|
|
|
|
|
|
| |
RELNOTES: Adds a sha256 attribute to git_repository and new_git_repository.
This can only be used if the remote is a public GitHub repository. It forces
Bazel to download the repository as a tarball, which will often be faster and
more robust than cloning it.
#2147.
PiperOrigin-RevId: 155223382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rule is responsible for building the target and instrumentation APKs used by an Android instrumentation test. If they are provided as APKs (e.g. from an android_binary or a genrule) they will be used as is. If they are provided as libraries, APKs will be created. This CL does not actually implement building target and instrumentation APKs from libraries, that will come in a follow-up CL as it will require some heavy refactoring of AndroidBinary.java.
Follow-up CLs will add features such as repackaging the APKs to remove duplicate classes, reproguarding the target APK with the test code, validating that the target and instrumentation APKs were signed with the same debug key and verifying that instrumentation stanza appears in the instrumentation APKs manifest.
Note that this CL does _not_ install the rule in the BazelRuleClassProvider, so
this CL does not make it usable by anyone. Once the other android testing rules are ready, I will install them all.
One small step towards https://github.com/bazelbuild/bazel/issues/903.
RELNOTES: None
PiperOrigin-RevId: 155220900
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 155209610
|
|
|
|
|
|
| |
This constrains implementations less, allowing for greater freedom when optimizing.
PiperOrigin-RevId: 155203001
|
|
|
|
|
|
| |
Fixes #2915
PiperOrigin-RevId: 155201382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
rules_docker is again the default.
*** Original change description ***
Automated g4 rollback of commit 70d8c32e8f7b97413a4e88e219114c117deedb8b.
*** Reason for rollback ***
Rolling back the switch to rules_docker due to substantial performance regression in certain actions.
*** Original change description ***
Emit warnings when the bundled docker_build and docker_bundle rules are used.
PiperOrigin-RevId: 155195712
|
|
|
|
| |
PiperOrigin-RevId: 155194438
|
|
|
|
|
|
|
|
|
| |
through `singlejar --normalize`.
Fixes #2912.
RELNOTES: None.
PiperOrigin-RevId: 155193074
|
|
|
|
|
|
|
|
|
|
| |
Issue like #2939 are impossible to debug due to missing
jvm.log, make the test framework print it before dying if
the error log output the jvm.log
Fixes #2939 (at least the part we can act on).
PiperOrigin-RevId: 155192458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add compile_jars Skylark accessor to JavaProvider. This outputs the
non-recursive set of jars needed to build with this target. Allows
Skylark tools to get the same set of compile_jars that JavaLibrary is
getting.
Added test that verifies Skylark was getting lists from both
compile_jars and transitive_runtime_jars of the expected length. Then,
verified (via test code) those nested sets were identical to the ones
provided by the java_library.
To reviewers:
First, would like to add documentation flags to these fields in
JavaProvider. Is it possible, instead of adding them to this map to
follow use the @SkylarkCallable annotation to expose methods on
JavaProvider instead? It would then also be nice to mark these as
experimental since won't really know the final API until
java_skylark_library sandwich is done.
I also tested this locally via bazel build //src:bazel and then doing
~/bazelsandbox/bazel/bazel-bin/src/bazel test SomeTarget in a different
repo that had a .bzl file trying to use compile_jars.
Change-Id: I1779c1b6303f36e50076c3479bfcb15a25aa95d8
PiperOrigin-RevId: 155191816
|
|
|
|
|
|
|
|
|
|
| |
We use fail pretty early in the script and not having
the fail function leads to non useful message about
the fail function not existing.
Fixes #2949.
PiperOrigin-RevId: 155186880
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the build event protocol to be able to report configurations;
in this way, we can distinguish, for which configuration a target
completed, a test passed, etc.
Note that this change allows for an additional expansion step: patterns
can be expanded to unconfigured targets that get configured in a
separate expansion step.
Change-Id: I31442796f57fe9acebc3cb5044e03087c4e4fd59
PiperOrigin-RevId: 155186365
|
|
|
|
|
|
|
|
|
|
| |
Move the position of the timestamp to the beginning of the line to
have a more readable log. Also, show the timestamp for progress as
well. While there, reduce timestamp to second precision, to reduce
noise.
Change-Id: Ibfa6caca2e0d207f54e3660bccbf894bba3c5ae3
PiperOrigin-RevId: 155181731
|
|
|
|
|
|
|
|
| |
"server.log" is not written anymore, what goes in now is:
cmdline, jvm.out and server.starttime.
Change-Id: I81b8c1d2647001e2c9c2bf3f1fc304d348033ef3
PiperOrigin-RevId: 155174690
|
|
|
|
|
|
| |
This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS.
PiperOrigin-RevId: 155171725
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/509.
Example output:
```
$ bazel build //:all
INFO: Found 1 target...
ERROR: /usr/local/google/home/ajmichael/.cache/bazel/_bazel_ajmichael/7fcc7480abc634522e5c0cfe6b85b583/external/bazel_tools/tools/android/BUILD:236:1: Executing genrule @bazel_tools//tools/android:no_android_sdk_repository_error failed: Process exited with status 1 [sandboxed].
This build requires an Android SDK. Please add the android_sdk_repository rule to your WORKSPACE.
Use --strategy=Genrule=standalone to disable sandboxing for the failing actions.
Target //:lib failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.327s, Critical Path: 0.10s
```
RELNOTES: Attempting to build an Android target without setting up android_sdk_repository will now produce a helpful error message.
PiperOrigin-RevId: 155158667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rule simply provides a shell script that is run on a device as part of a
test which can come from an input file or as a string command.
It also takes a list of APKs that need to be installed before the fixture can
be run.
Note that this CL does _not_ install the rule in the BazelRuleClassProvider, so
this CL does not make it usable by anyone. Once the other android testing rules are ready, I will install them all.
One small step towards https://github.com/bazelbuild/bazel/issues/903.
RELNOTES: None
PiperOrigin-RevId: 155155984
|
|
|
|
|
|
|
| |
Since https://github.com/bazelbuild/bazel/issues/2709 was fixed, this CL also enables ParsedAndroidDataTest.
RELNOTES: None
PiperOrigin-RevId: 155155095
|
|
|
|
|
|
| |
The file is AbstractPackageLoaderTest.java not AbstractBazelPackageLoaderTest.java.
PiperOrigin-RevId: 155138964
|
|
|
|
| |
PiperOrigin-RevId: 155131707
|
|
|
|
|
|
|
| |
Also, open source two more tests.
RELNOTES: None
PiperOrigin-RevId: 155129416
|
|
|
|
| |
PiperOrigin-RevId: 155125357
|
|
|
|
|
|
| |
(http://ci.bazel.io/job/bazel-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/lastBuild/console).
PiperOrigin-RevId: 155122394
|
|
|
|
|
|
|
|
| |
Re-organize ObjcLibraryTest and ExperimentalObjcLibraryTest ->
LegacyObjcLibraryTest and CrosstoolObjcLibraryTest, according to the pattern used in
the other unit tests.
PiperOrigin-RevId: 155120143
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 155113548
|
|
|
|
|
|
|
|
|
| |
If the list of direct deps is empty, it's either because the action doesn't
distinguish between direct and transitive deps, or because the target has no
deps at all. The 'direct classpath optimization' can still be applied in the
latter case.
PiperOrigin-RevId: 155112465
|
|
|
|
|
|
|
| |
AttrFunction and LabelsFunction are also made public.
RELNOTES: None
PiperOrigin-RevId: 155108260
|