| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
SpawnAction on Windows.
RELNOTES: None.
Change-Id: I2d926447511dab5fb804051abdbef9031cb089be
PiperOrigin-RevId: 162201440
|
|
|
|
|
|
|
| |
We now have the ExtendedEventHandler, which is available in all the relevant
code paths, so we just post the event directly.
PiperOrigin-RevId: 162200923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
It breaks examples/tutorial on ci.bazel.build [1] with error:
object of type 'Target' has no field 'objc'.
[1] http://ci.bazel.io/view/Dashboard/job/Tutorial/BAZEL_VERSION=HEAD,PLATFORM_NAME=darwin-x86_64/1023/console
*** Original change description ***
AppleBinary and AppleStaticLibrary no longer propagate unwrapped ObjcProvider.
This will prevent dependencies on apple_binary and apple_static_library from objc_library and other lower-level rules.
RELNOTES: None.
PiperOrigin-RevId: 162195726
|
|
|
|
| |
PiperOrigin-RevId: 162194755
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise it logs warnings that look like this:
170714 08:16:28.552:WT 18 [io.grpc.netty.NettyServerHandler.onStreamError]
Stream Error io.netty.handler.codec.http2.Http2Exception$StreamException:
Received DATA frame for an/ unknown stream 11369
As far as we can tell, these do not indicate any problem with the connection.
We believe they happen when the local side closes a stream, but the remote
side hasn't received that notification yet, so there may still be packets for
that stream en-route to the local machine. The wording 'unknown stream' is
misleading - the stream was previously known, but was recently closed. I'm
told upstream discussed this, but didn't want to keep information about
closed streams around.
PiperOrigin-RevId: 162194736
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- add an id for logging; this allows us to correlate log entries for the same
spawn from multiple spawn runner implementations in the future
- add a prefetch method to the SpawnExecutionPolicy; better than relying on
the ActionInputPrefetcher being injected in the constructor
- add a name parameter to the report method; this is in preparation for a
single unified SpawnStrategy implementation - it's basically the last bit of
difference between SandboxStrategy and RemoteSpawnStrategy; they're otherwise
equivalent (if not identical)
PiperOrigin-RevId: 162194684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit:
- deprecates PathListConverter
- removes ExistingPathListConverter because it was
not used in production, only tests
- deprecated List<Path> type flags that use
PathListConverter
- introduces new List<Path> type flags next to the
deprecated ones that use @Options.allowMultiple
and convert with PathConverter; the new and old
lists are concatenated, yielding the flag value
PathListConverter and all of its occurrences
should be removed after 2018-01-31 (about 6 months
from now, which is a safe enough timeframe for
everyone to upgrade Bazel so it uses the new-style
flags).
Reason for deprecation is that colon-separated
path lists don't work on Windows because paths
have colons in them.
Since the Android BusyBox is not intended to be
executed by users but by Bazel only, there's no
release notes necessary.
See https://github.com/bazelbuild/bazel/issues/3264
RELNOTES: none
PiperOrigin-RevId: 162193998
|
|
|
|
|
| |
Change-Id: Iaa957c8ad597c2f4fedb5beb4bd8bc4df89fdbe1
PiperOrigin-RevId: 162186695
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lower the chances of triggering #3360. Immediately before uploading
output artifacts, check if any of the inputs ctime changed, and if
so don't upload the outputs to the remote cache.
I profiled the runs on //src:bazel before vs. after the change; as expected, the
number of VFS_STAT increases by a factor of 180% (!), but, according to the profiler,
it adds less than 1ms to the overall build time of 130s.
PiperOrigin-RevId: 162179308
|
|
|
|
|
|
|
|
|
|
|
| |
Two cases:
- The upload succeeds and the Chunker consumes all its data and closes
the underlying data source.
- The upload fails and the Chunker doesn't close the data source, and
so we call reset() manually.
RELNOTES: None.
PiperOrigin-RevId: 162178032
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 162135034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamically Configured Resource Filtering change 3/6
Resource filtering behaves somewhat differently when dynamically configured.
Resources obtained from dependencies will have already been filtered and do not
need to be filtered again. Resources that were filtered out do not need to be
tracked since resource processing will never receive a reference to them
anyway.
Also, to make builds where ResourceFilter is dynamically configured, add equals
and hashCode methods (otherwise, the configuration code throws a
NullPointerException) and a global output prefix (otherwise, conflicts can
occur).
To ensure that the global output prefix (and the ResourceFilter object itself)
is the same regardless of the ordering of filters in the android_binary, build
the filters into a set, not a list, and sort them as part of creating the
ResourceFilter object. This way, for example, objects built with filters
"en,fr", "fr,en", and "en,en,fr" will all end up equal.
Finally, rename the getFilteredResources method to better reflect its new role,
and improve the isPrefiltering method to not try to prefilter if there are no
filters.
Add tests for all of this, and helper methods for all of those tests, including,
most notably, a makeResourceFilter method that instantiates a ResourceFilter
similarly to how it is actually created outside of tests (rather than directly
calling the constructor) and a fake implementation of AttributeMap to support
this.
RELNOTES: none
PiperOrigin-RevId: 162099178
|
|
|
|
| |
PiperOrigin-RevId: 162039650
|
|
|
|
|
|
|
|
| |
for configuring additional Java compilation tools, which are
added as inputs to javac and turbine actions and available
for jvm_opts location expansion.
PiperOrigin-RevId: 162036912
|
|
|
|
|
|
|
| |
This will prevent dependencies on apple_binary and apple_static_library from objc_library and other lower-level rules.
RELNOTES: None.
PiperOrigin-RevId: 162013946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamically Configured Resource Filtering change 2/6
We need to filter LocalResourceContainer for dynamically configured resource
filtering - it is an input to resource parsing for android_library targets.
Filter it appropriately.
Once it's being filtered, use it to build a filtered ResourceContainer, rather
than building an unfiltered ResourceContainer and then filtering it. This means
filtering gets done sooner, saving a bit of time and work, and isn't done
twice, which would just be bad.
To do this, we pass an unbuilt ResourceContainer.Builder into createApk, rather than a fully built one. Move the setAssetsAndResourcesFrom and setManifest calls to that builder, called every time, into createApk so that we only call them once.
Also, initialize the ResourceFilter object when it's needed, rather than pass
it down from the binary or library. This makes the code a bit cleaner, plus
means library targets will pick up the dynamically configured information once
that exists.
RELNOTES: none
PiperOrigin-RevId: 162007885
|
|
|
|
|
|
|
| |
Now that we have the options before calling beforeCommand, there's no need for
a separate handleOptions method in the BlazeModule API. Remove it.
PiperOrigin-RevId: 162002300
|
|
|
|
|
|
|
|
|
| |
Motivation: properly document config_setting.values.
The license type description is terse. But that's an obscure
feature we don't really want to focus attention on.
PiperOrigin-RevId: 161998339
|
|
|
|
|
|
|
|
|
|
| |
In order to break out the proto dependency of the OptionsParser, add a java-only enum that users of the options parser can depend on, instead of requiring the dependency on the protobuf. The protocol buffer definition is kept in order to be used for command line reporting in the BEP, so a test is added to make sure that the two are kept in sync.
Also add some clearer guidance for how to go about selecting, and adding, option categories and tags.
Migrating the current uses of the proto enum to this one will happen in a follow-up change.
PiperOrigin-RevId: 161971077
|
|
|
|
|
|
|
| |
If a reserved mnemonic is used, it is mangled.
RELNOTES:
PiperOrigin-RevId: 161970885
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161970540
|
|
|
|
|
|
|
|
| |
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: 161970449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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
|