| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main change here is to only catch SpawnExecException in
StandaloneTestStrategy, so all other exceptions simplify propagate up. As a
result, Bazel no longer retries tests that fail with an exception, we only
retry tests that actually ran, had a spawn result, and resulted in a
UserExecException. That is probably what we want.
Also do some cleanup:
- Remove ExecException.timedOut; nobody was calling it (but there's still
SpawnExecException.timedOut)
- Remove SpawnActionContext.shouldPropagateExecException; all exceptions
(except SpawnExecException) are now propagated by default
- Remote the SandboxOptions from the SandboxStrategies; all sandboxing options
are now handled by the underlying SpawnRunner implementations
I'll send a followup CL to remove the UserExecException and
EnvironmentalExecException types; the types don't do anything special, and
there are no catch blocks in production code that catch one of these more
specific types.
This should fix #3322 by removing a bunch of special handling.
PiperOrigin-RevId: 161960919
|
|
|
|
|
|
|
|
|
| |
RoundRobin client side load balancer instead of the default PickFirst.
A RoundRobin rotates between all addresses returned by the resolver, while PickFirst sends all traffic to the first address. This might help resolve some of the load problems we encountered (see https://github.com/grpc/grpc/issues/11704 for more details).
TESTED=remote worker
PiperOrigin-RevId: 161960008
|
|
|
|
|
|
|
|
| |
Retry execution when we think it's ETXTBSY.
Fixed #3356.
PiperOrigin-RevId: 161958095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit:
- remove unused methods and classes
- turn CustomCommandLine.ArgvFragment into an
interface
- remove the
CustomCommandLine.TreeFileArtifactArgvFragment
abstract class; it only had one remaining
subclass
- add @Nullable annotations where nulls are fine
- add Precondition checks for non-nullable args
- simplify the interface by removing add* methods
that can be composed of other add* methods; this
makes it easier to see what the callers do with
the Builder
- remove add* methods that add a single argument
followed by a list of other elements (or a
joined string of them); these had a bug in that
they didn't check if the collection was empty
(only that it was not null), and if it was empty
then the single argument was still added though
it was not followed by any value
- fix call sites of add* methods where we
previously could have added a flag with an empty
collection
- audit every affected call site
RELNOTES: none
PiperOrigin-RevId: 161957521
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3384
RELNOTES: none
PiperOrigin-RevId: 161952950
|
|
|
|
|
|
|
|
|
|
| |
The C++ link for Go links involving C++ objects did not add linker options from feature
configurations in the crosstool to the link line. This caused failures in go_test links when linking with LIPO, since a recent change moved the necessary link options to the crosstool feature config (e.g. unknown commit), instead of explicitly specifying them for the tests.
This issue affected other link types as well (I confirmed that an --fdo_instrument link of a go_binary failed because it did not pick up the necessary link options from the feature config).
RELNOTES: None.
PiperOrigin-RevId: 161952640
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161952410
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For commands that do not send a BuildFinishedEvent, we normally use the
NoBuildEvent to determine the end of the build and hence the moment
where the UI should not any more interfere with the output. For some
requests, like fetch, however, we should continue to report progress
till the very end (as there is no output to interfere with). Do so,
and also be sure that the experimental UI also reports downloads if
not explicitly in a loading or analysis phase.
While there, also group digits in the number of downloaded bytes, to
increase readability.
Change-Id: I31efeee5bdb1d29b2ecf842acb3e383e297707f8
PiperOrigin-RevId: 161935456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To update the progress bar, we first have to remove it and then write the
new one. For this to look smooth, the control sequence removing the old progress
bar and the characters of the new progress bar have to arrive "in one go" at the
(actual) terminal. As AnsiTerminal sends each control sequence as a separate write
to the underlying stream, we have to buffer the underlying stream. Therefore,
if the experimental UI is used, buffer that stream unconditionally until flushed,
and not by line. For the experimental UI this is save, as it flushes the stream
appropriately.
For the old UI, we keep the line buffering, as the old UI relies on an implicit flush
whenever a new-line character is written.
Change-Id: I3a914e4b93ce17c3de05df0d860cf98849c3b4a1
PiperOrigin-RevId: 161935218
|
|
|
|
|
|
|
|
|
| |
Python tests.
RELNOTES: None.
Change-Id: I76c4f11323b1c0690e20d54f129abd671275acb0
PiperOrigin-RevId: 161934858
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 161930826
|
|
|
|
|
|
|
|
| |
Resolves #2571
Closes #3316.
PiperOrigin-RevId: 161930376
|
|
|
|
|
|
| |
Close #3378.
Change-Id: I8ab58b00d5d8b86880c45f05feb139c01e0368aa
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/3366
RELNOTES: None
PiperOrigin-RevId: 161926642
|
|
|
|
| |
PiperOrigin-RevId: 161925075
|
|
|
|
|
|
|
| |
It turns out that I didn't read the docs, and the previous settings resulted
in a single-threaded executor.
PiperOrigin-RevId: 161924238
|
|
|
|
|
|
|
|
|
|
| |
The Chunker should only open a file on the first call to next(). We
noticed that when remote executing with hundreds of actions in parallel
bazel would sometimes run out of file descriptors. That's because on
creating a new Chunker object it would already open a file, eventhough
the first call to next would happen at a much later stage.
PiperOrigin-RevId: 161923568
|
|
|
|
|
|
| |
TESTED=remote worker
RELNOTES: fixes #3380
PiperOrigin-RevId: 161922635
|
|
|
|
|
|
|
|
|
|
|
| |
information from the BUILD files and determining what to do with them is separated.
This is so that we can eventually determine this information not in AppleConfiguration.Loader, but in the implementation of the xcode_config rule so that the former doesn't need to look at BUILD files anymore.
Of course, this requires changing Skylark code that uses ctx.fragments.apple.$WHATEVER, but it's a good first step.
RELNOTES: None.
PiperOrigin-RevId: 161916770
|
|
|
|
| |
PiperOrigin-RevId: 161910195
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 161850684
|
|
|
|
|
|
|
|
| |
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
|