| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
constructing the package with an error.
Prior to this change, if a Package.Builder object was constructed, it was guaranteed that a Package (possibly with errors) would be created. This is no longer true: if an IOException is set on the Package.Builder object, it will throw a NoSuchPackageException during #build().
PiperOrigin-RevId: 161832111
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 161831232
|
|
|
|
|
|
| |
This allows users to specify a custom module map.
PiperOrigin-RevId: 161827651
|
|
|
|
|
|
|
| |
Part of #2219.
Change-Id: I339009c13639144ca756eb07c520df7d430a64e3
PiperOrigin-RevId: 161826487
|
|
|
|
| |
PiperOrigin-RevId: 161821800
|
|
|
|
|
|
|
| |
Also refactor FAIL_FAST_HANDLER to throw something more specific than IllegalArgumentException. This bug was masked because the test assertion that would've caught it considered IllegalArgumentException to be an expected error, the same as EvalException.
RELNOTES: None
PiperOrigin-RevId: 161809957
|
|
|
|
|
|
|
|
|
|
| |
their own.
The alias_rules.bzl hack is required because Bazel at HEAD needs to be able to be built
with released Bazel, which doesn't know these rules yet.
RELNOTES: None.
PiperOrigin-RevId: 161808672
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Do not rely on the README.md anymore, because it relies on log
still existing forever on Jenkins. Incoming change will just provides
the log as a file that will be archived on GCS.
Change-Id: Ib962c249145d222bf9909070698c5d419b34db4c
PiperOrigin-RevId: 161804017
|
|
|
|
|
|
|
|
|
|
| |
favor of the cc_toolchain_alias() and the java_runtime_alias() rules introduced in https://github.com/bazelbuild/bazel/commit/440919933dc11d8aa4394dbd53790271a2073bc5.
These two serve the same purpose; the attributes were originally introduced in https://github.com/bazelbuild/bazel/commit/28c9617d53bf58dcba9572bcfdc165c62421d983 and https://github.com/bazelbuild/bazel/commit/4634ff903d1aaec59d545bd28a139d6cf2b95e0d respectively in order to avoid introducing the magic rule classes. However, the magic rule classes needed to be introduced anyway so that existing rules can declare which Make variables they use and there is no point in having two mechanisms to do the same thing.
RELNOTES[INC]: cc_common.cc_toolchain_attr and java_common.java_runtime_attr are not supported anymore and were replaced with the cc_toolchain_alias() and java_runtime_alias() rules.
PiperOrigin-RevId: 161799608
|
|
|
|
|
|
| |
Fixes #3373.
PiperOrigin-RevId: 161799558
|
|
|
|
|
|
|
|
|
| |
DefaultInfo used to not be used when old-style and declared providers were
mixed (struct=(custom='key', providers=[DefaultInfo(...)])).
Also when a single declared provider was returned it used to be treated as an
old-style struct.
PiperOrigin-RevId: 161796415
|
| |
|
|
|
|
| |
PiperOrigin-RevId: 161789899
|
|
|
|
|
|
|
|
|
|
| |
Whenever we report an action in the build event protocol that has
a configuration associated with it, report the configuration as
well in the protocol (and not only the checksum, if the configuration
is not that of one of the top-level configured targets).
Change-Id: I9b085d5381b3c3509b4f3b99c8a77bc8fba6abfe
PiperOrigin-RevId: 161789745
|
|
|
|
|
|
|
|
| |
java_toolchain_alias() rule, depending on which will accomplish the same thing.
RELNOTES[INC]: java_common.java_toolchain_attr is removed. Depend on the java_toolchain_alias() rule to accomplish the same thing.
PiperOrigin-RevId: 161789578
|
|
|
|
|
|
|
|
|
| |
rules to declare which Make variables they need.
The idea is that they would depend on the future java_runtime_alias / cc_toolchain_alias and similar rules and thus Bazel will know which Make variables they actually need instead of pulling in the whole BuildConfiguration and also making it possible to compute these Make variables during analysis instead of configuration creation.
RELNOTES: None.
PiperOrigin-RevId: 161785868
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161785358
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel's fetch command is also related to building. So generate
a build-event stream for this as well. As a first step, generate
a minimal stream with only the console output by white listing
the command, setting the separateFinishedEvent flag on the
NoBuildEvent, and generating a NoBuildRequestFinishedEvent.
Change-Id: Iee0c4e84ee5a060565ac86692a2b1917691a84ab
PiperOrigin-RevId: 161782448
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently `rlocation` is not defined in the
environment of regular sh_binary rules, only in
tests. So this commit adds an implementation for
it.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I70ecb91cef5e1b66679e6ba04823831183da5cd9
PiperOrigin-RevId: 161775438
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161774151
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161772560
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161734511
|
|
|
|
|
|
|
| |
were being falsely logged during build as warnings
RELNOTES: none
PiperOrigin-RevId: 161723206
|
|
|
|
|
|
| |
TESTED=remote worker, triggered some errors
RELNOTES: fixes #3305, helps #3356
PiperOrigin-RevId: 161722997
|
|
|
|
|
|
|
| |
Part of #2219.
Change-Id: I7293fd13bd8e0931f92afd051e18a9e7ce63762d
PiperOrigin-RevId: 161721445
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161720296
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an output file becomes a directory from one build to another, the
filesystem operations performed by several threads can race while they
prepare output directories. Without synchronization, these races can
cause failures. See the comments added in this CL for more detail.
This CL adds synchronization around these filsystem operations and gets
rid of the problematic races.
RELNOTES: None.
PiperOrigin-RevId: 161714702
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/runtime/BlazeRuntime.java#L1097, we log exceptions in the EventBus already. No need to have a crusty auxiliary class.
PiperOrigin-RevId: 161707461
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161706309
|
|
|
|
| |
PiperOrigin-RevId: 161693427
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 161670197
|
|
|
|
|
|
|
| |
Should be USE_MSVC_WRAPPER instead NO_MSVC_WRAPPER now.
RELNOTES: None
PiperOrigin-RevId: 161668110
|
|
|
|
|
|
|
|
| |
This adds a bunch of classes that only implement the SpawnRunner interface, and
will allow us to support remote caching in combination with local sandboxed
execution in a subsequent change.
PiperOrigin-RevId: 161664556
|
|
|
|
|
|
|
|
|
|
| |
- Only pass to the GrpcRemoteExecutor constructor the objects it really
needs.
- Share a Retrier between GrpcRemoteCache and GrpcRemoteExecutor.
RELNOTES: None
PiperOrigin-RevId: 161660054
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Almost) all native declared providers are accessed as such and not as
native non-declared providers (inheritors of TransitiveInfoCollaction).
There are still three providers that use
TransitiveInfoCollection.WithLegacySkylarkName mechanism, I'll address
them in the follow-up CL.
RELNOTES: None.
PiperOrigin-RevId: 161655315
|
|
|
|
|
|
|
|
|
| |
set USE_MSVC_WRAPPER=1 if you still want to use wrapper script.
RELNOTES:
Windows: Wrapper-less CROSSTOOL becomes default now.
set USE_MSVC_WRAPPER=1 if you still want to use wrapper script.
PiperOrigin-RevId: 161654018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- --experimental_strict_action_env makes Bazel not forward PATH,
LD_LIBRARY_PATH, and TMPDIR to all actions. This is intended to be a
transitional flag; as part of rollout, we'll need to update all users that
rely on the current behavior to specify their needs explicitly (with
--action_env). But note that action_env is not yet applied to all actions,
which also needs to be fixed.
- --shell_executable can be used to explicitly set the shell executable to
use in actions. On Windows, if --experimental_strict_action_env is unset,
then the PATH is computed to include the path to the shell executable.
Progress on #2574.
PiperOrigin-RevId: 161652996
|
|
|
|
|
|
|
|
| |
The method is moved to FeaturePolicyConfiguration.java so that it can be used
by unrelated parts of the code using feature policies for whitelisting.
RELNOTES:none
PiperOrigin-RevId: 161648169
|
|
|
|
|
|
|
|
|
|
| |
The existing support for including a flat list of labels was moved to the `srcs` attribute.
See https://github.com/bazelbuild/bazel/issues/3317 for context and motivation.
Closes #3318.
PiperOrigin-RevId: 161645944
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make use of existing abstractions like SpawnRunner and SpawnExecutionPolicy.
- Instead of having the *Strategy create a *Runner, and then call back into
SandboxStrategy, create a single SandboxContainer which contains the full
command line, environment, and everything needed to create and delete the
sandbox directory.
- Do all the work in SandboxStrategy, including creation and deletion of the
sandbox directory.
- Use SpawnResult instead of throwing, catching, and rethrowing.
- Simplify the control flow a bit.
PiperOrigin-RevId: 161644979
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sameBlobsShouldNotBeUploadedTwice() test was found flaky on bazel ci
[1]. This can happen when the first upload finishes before the second is
started.
Add a CountDownLatch to stop the first upload from completing, before the
second is started.
[1] https://github.com/bazelbuild/bazel/issues/3348
PiperOrigin-RevId: 161641110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
| |
Change-Id: Iaaf3272f45cce04d41e75ffbe2fa5b5b9f68734c
RELNOTES: None.
|
|
|
|
| |
Change-Id: I8b0f4e7547358704d038db312795c58acaaac4a7
|
|
|
|
|
|
|
|
| |
And instead rely on the flags being set in java_toolchain.jvm_opts.
This change is being made in preparation for JDK 9, which replaces
-Xbootclasspath/p with --patch-module.
PiperOrigin-RevId: 161620182
|
|
|
|
|
|
|
|
|
|
| |
As far as I can tell this is largely equivalent to the current behaviour:
* Instead of discovering inputs in ExtraAction and adding its own runfiles supplier, just pass the composite one in the first place and let the normal thing happen
* The mnemonic returned by the override seems to be equivalent to the one from the extra action anyway, which is what the base class does
* The extra action key will change slightly as it will now include the composite runfiles supplier, but I can't see how that would be a problem.
PiperOrigin-RevId: 161608100
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 161588977
|
|
|
|
| |
PiperOrigin-RevId: 161582236
|
|
|
|
|
|
| |
RELNOTES: none
TESTED=remote worker
PiperOrigin-RevId: 161572597
|