| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
order to allow tests that depend on pruned inputs to work for both the legacy
and crosstool cases.
PiperOrigin-RevId: 161955432
|
|
|
|
|
|
|
|
| |
Fixes #3367.
This is useful when implementing rules that comply with the strict deps feature.
PiperOrigin-RevId: 161955236
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#3379
Commit dc24004873c335 broke the upload of locally executed action
results. Also, update our unit tests who did not catch this error.
P.S.: olaola@ is the author of this change, but due to time constraints
we had to merge it while she was asleep.
Change-Id: Ib150152c0bddc8311908c105aef208506d3b6a8d
PiperOrigin-RevId: 161954553
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161952410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke various Bazel CI jobs
Fixes https://github.com/bazelbuild/bazel/issues/3388
Fixes https://github.com/bazelbuild/bazel/issues/3386
Fixes https://github.com/bazelbuild/bazel/issues/3385
Fixes https://github.com/bazelbuild/bazel/issues/3384
*** Original change description ***
Fix rules that provide both 'executable' and 'files'
PiperOrigin-RevId: 161949099
|
|
|
|
|
|
|
|
|
|
|
| |
- Move flag handling into RemoteModule to fail as early as possible.
- Make error messages from flag handling human readable.
- Fix a bug where remote execution would only support TLS with a root
certificate being specified.
- If a remote executor without a remote cache is specified, assume the
remote cache to be the same as the executor.
PiperOrigin-RevId: 161946029
|
|
|
|
| |
PiperOrigin-RevId: 161944209
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161937673
|
|
|
|
|
|
|
|
| |
Fixes an issue where an aspect propagates over a target that depends on another target
twice with different set of aspects applied.
RELNOTES: None.
PiperOrigin-RevId: 161931168
|
|
|
|
|
|
|
|
| |
Resolves #2571
Closes #3316.
PiperOrigin-RevId: 161930376
|
|
|
|
| |
PiperOrigin-RevId: 161925075
|
|
|
|
|
|
|
| |
This was causing some builds to error more aggressively than before.
RELNOTES: None.
PiperOrigin-RevId: 161907484
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 161892267
|
|
|
|
|
|
|
|
| |
in some situations (which I don't fully understand).
Fixes failing Bazel test.
PiperOrigin-RevId: 161874315
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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: 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: 161706309
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- --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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke the go rules (of course)
See http://ci.bazel.io/job/rules_go/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/1044/console.
*** Original change description ***
Resolve references to @main-repo//foo to //foo
Bazel was creating an dummy external repository for @main-repo, which
doesn't work with package paths and will cause conflicts once
@main-repo//foo and //foo refer to the same path.
This adds a "soft pull" option to WorkspaceNameFunction: it can either
parse the entire WORKSPACE file to find the name or just the first section.
That way PackageLookupFunction can find the repository name without causing
a circular dependency.
This should have no ch...
***
PiperOrigin-RevId: 161572272
|
|
|
|
|
|
| |
*** Reason for rollback ***
PiperOrigin-RevId: 161567104
|
|
|
|
|
| |
RELNOTES: Remove apple_watch1_extension and apple_watch_extension_binary rules. Users should be using the skylark watchos_application and watchos_extension rules. https://github.com/bazelbuild/rules_apple has details.
PiperOrigin-RevId: 161555395
|
|
|
|
|
|
|
|
|
| |
- changed field names and a couple accessors to consistently use full words ("statement" instead of "stmt")
- applied several local analyzers (from IntelliJ) to remove redundant modifiers, unnecessary explicit types (yay Java 8), etc.
RELNOTES: None
PiperOrigin-RevId: 161551096
|
|
|
|
|
|
|
|
| |
Don't call the `toString` method on unknown objects as it potentially
breaks hermeticity and determinism. Use a generic string like
"<unknown object package.ClassName>" instead.
PiperOrigin-RevId: 161544828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel was creating an dummy external repository for @main-repo, which
doesn't work with package paths and will cause conflicts once
@main-repo//foo and //foo refer to the same path.
This adds a "soft pull" option to WorkspaceNameFunction: it can either
parse the entire WORKSPACE file to find the name or just the first section.
That way PackageLookupFunction can find the repository name without causing
a circular dependency.
This should have no change of behavior and is already tested in
https://github.com/bazelbuild/bazel/blob/master/src/test/shell/bazel/workspace_test.sh#L176.
PiperOrigin-RevId: 161536466
|
|
|
|
|
|
|
|
| |
This value can be passed in Skylark to java_common.compile#java_toolchain in
order to avoid incompatibility issues when the value of --java_toolchain uses a
different Java version.
PiperOrigin-RevId: 161528114
|
|
|
|
|
|
|
|
|
| |
to use.
Part of #2219.
Change-Id: Id6dfe6ec102f609bb19461242a098bf977be29ae
PiperOrigin-RevId: 161527986
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161527470
|
|
|
|
| |
PiperOrigin-RevId: 161521237
|
|
|
|
|
|
|
|
| |
The test now uses a fake clock and replaces calls to Thread.sleep() by manual
changes to the clock.
RELNOTES:none
PiperOrigin-RevId: 161520781
|
|
|
|
|
|
|
|
|
|
|
| |
can depend on the C++ toolchain/Java runtime being used.
The naive way to do this would be via @bazel_tools//, except that that does not take configuration transitions into account and e.g. will be the same in the host and the target configurations even if different toolchains are used.
Eventually, this will be supplanted by the toolchain selection mechanism. However, that is not live yet and the migration cost this will incur is not a lot; just replacing the one single instance of these undocumented rules with the reference to the toolchain type.
RELNOTES: None.
PiperOrigin-RevId: 161519229
|
|
|
|
|
|
|
|
|
|
| |
OptionMetadataTags.
These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead.
Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category.
PiperOrigin-RevId: 161515674
|
|
|
|
|
|
|
|
|
|
|
| |
From a BEP point of view, the only interface of a configuration we care
about is its BuildEvent structure. Represent it as such, so that we
can move this class to the rest of the buildeventstream module. This
is a prerequisite for ActionOwners refering to configurations in the
BEP.
Change-Id: I6d1c1bf2951aac91607e83cad664553cd6620df8
PiperOrigin-RevId: 161510049
|