| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|