| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
| |
define a binary_under_test.
They are filtered out for deployment anyways so it's unnecessary work and it
confuses the one version detector.
RELNOTES: n/a
PiperOrigin-RevId: 184725205
|
|
|
|
|
|
|
|
|
|
|
|
| |
Filtering only in analysis was neglecting the possibility of resources being in
filesets, the contents of which are not available in analysis. As such, we must
*always* filter in execution, even though it's usually just going to be a
no-op.
Also, add some documentation of same.
RELNOTES: none
PiperOrigin-RevId: 184722564
|
|
|
|
| |
PiperOrigin-RevId: 184720361
|
|
|
|
| |
PiperOrigin-RevId: 184710375
|
|
|
|
|
|
|
|
|
| |
execution platforms.
Part of #4442.
Change-Id: I6678d57f4aaadcb19032bf58820606242ba66a25
PiperOrigin-RevId: 184707708
|
|
|
|
|
|
|
| |
series. The following CLs will integrate this into bazel.
RELNOTES:n/a.
PiperOrigin-RevId: 184706507
|
|
|
|
|
|
| |
Looks like this got missed.
PiperOrigin-RevId: 184701334
|
|
|
|
|
|
|
| |
file.
Change-Id: I5b66b91f016e12e546600f585546fc56d9511303
PiperOrigin-RevId: 184698749
|
|
|
|
|
|
|
|
|
| |
We apparently don't have any other implementations of these interfaces than
BlazeCommandDispatcher, so let's not have them at all; we can always put back
an interface with the exec() method if need be.
RELNOTES: None.
PiperOrigin-RevId: 184698573
|
|
|
|
|
|
| |
field type information.
PiperOrigin-RevId: 184695891
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the mock java file in
//src/test/py/bazel:runfiles_test to an actual
file in the source tree. This change makes the
test more readable, and the file more easily
discoverable.
See https://github.com/bazelbuild/bazel/issues/4460
Change-Id: I94b033f63b218554b0e0e11814fde4c13bf7cca0
PiperOrigin-RevId: 184692391
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184692000
|
|
|
|
| |
PiperOrigin-RevId: 184689620
|
|
|
|
|
|
|
|
|
|
|
|
| |
compiled as part of bazel's repository bootstrap. This should make crosstool's clang invocations faster. An added benefit of this is that wrapped_clang.cc supports the "DSYM_HINT" flags specified through the CROSSTOOL, so with this change, apple_binary gets support for the --apple_generate_dsym flag.
The dSYM generation issue has been flagged multiple times:
https://github.com/bazelbuild/bazel/issues/4312
https://github.com/bazelbuild/bazel/issues/3940
https://github.com/bazelbuild/bazel/issues/3372
RELNOTES: apple_binary can now generate dSYM outputs with the --apple_generate_dsym=true flag.
PiperOrigin-RevId: 184688215
|
|
|
|
|
|
| |
runtime check on the type of the iterable, performing custom serialization for a NestedSet.
PiperOrigin-RevId: 184686288
|
|
|
|
|
|
|
|
|
| |
This can be encapsulated in a device script fixture as an environment variable.
https://developer.android.com/studio/command-line/logcat.html#filteringOutput
RELNOTES: None.
PiperOrigin-RevId: 184683289
|
|
|
|
|
|
|
| |
should be shut down in BlazeCommandResult.
RELNOTES: None.
PiperOrigin-RevId: 184678994
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: I21baffe59431ccd3d76754596ec2a605dbbe4354
PiperOrigin-RevId: 184678470
|
|
|
|
|
|
|
| |
This is the second try for this CL. The first one caused Blaze to crash when building Exoblaze as shown in b/72936965. In this CL I fix the condition of when to generate non-PIC compilation actions for WrapCcHelper.
RELNOTES:none
PiperOrigin-RevId: 184671661
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184667932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Try again with fixes.
*** Original change description ***
Automated rollback of commit 10b0d8aa6b73a024cc007c5e075cb329add878ef.
*** Reason for rollback ***
Breaks Google-internal targets, sadly.
*** Original change description ***
Ban middlemen from runfiles artifacts.
Previous changes have removed all middlemen from runfiles
artifacts. This CL locks it down and removes various now-redundant
*WithoutMiddlemen() methods from Runfiles.
I put a check for middlemen in ConflictChecker.put, which should be a
chokepoint for runfiles arti...
***
PiperOrigin-RevId: 184661375
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the runfiles test's mock Python binary to
run another mock Python binary and assert that the
outer binary propagates the runfiles information
to the inner one.
See https://github.com/bazelbuild/bazel/issues/4460
Change-Id: I3bba799a376642196777f7bc988837084a53bc93
PiperOrigin-RevId: 184650962
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184649483
|
|
|
|
|
|
| |
Closes #4488.
PiperOrigin-RevId: 184648112
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184619885
|
|
|
|
| |
PiperOrigin-RevId: 184587712
|
|
|
|
|
|
| |
InjectingObjectCodec.
PiperOrigin-RevId: 184566571
|
| |
|
|
|
|
|
|
|
|
|
| |
instead of removing them, since builds that use modules need them to be
visible across compilation boundaries. Note that the module-infos don't
contain any implementation that needs to be removed, so ijar just copies
the entire file through.
PiperOrigin-RevId: 184562080
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
native skyframe implementation was actually quite incorrect in this case: It was adding a skyframe dependency on a FileValue for the output file. Without a transitive dependency on the source files and actions that determine the output file's state, this could never work (and explains why the incremental build would fail). Instead, we now depend on the Artifact corresponding to the output file instead.
This change updates the business logic RecursiveFilesystemTraversalFunction. This approach keeps the business logic of Fileset filesystem traversal centralized in RFTF.
To avoid making weird recursive Skyframe nodes in the output tree, we inline Skyframe dependencies and do direct filesystem operations over the output tree.
There are now three states we can be in when looking up a file:
1. Source file: As before, make a skyframe dep on the corresponding file
2. Top-level file of an output tree: Make a dep on the corresponding Artifact
3. Recursive file under an output directory: Do direct filesystem operations. It doesn't make sense to make Skyframe nodes corresponding to these files. In the future, I think we should consider failing fast on this case.
RELNOTES: None
PiperOrigin-RevId: 184556044
|
|
|
|
|
|
| |
since it's never instantiated on its own.
PiperOrigin-RevId: 184554483
|
|
|
|
|
|
|
|
| |
essentially promote OwnedArtifact to ArtifactSkyKey and rename it to ArtifactSkyKey. The king is dead...
Also add some other execution-phase codecs.
PiperOrigin-RevId: 184552706
|
|
|
|
| |
PiperOrigin-RevId: 184540561
|
|
|
|
|
|
|
|
|
|
|
| |
the runfiles tree.
As I understand it, this is only a theoretical issue today because
$unified_launcher is generally a flat file. (Flat files never have
runfiles middlemen.) However, it's good to be future proof.
Change-Id: If77edfa9dd7475ab93b19c62b08f8d86a77acbe6
PiperOrigin-RevId: 184540188
|
|
|
|
|
|
| |
SpecialArtifact.
PiperOrigin-RevId: 184539696
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184538771
|
|
|
|
|
|
|
|
| |
We're now using ctime to detect file changes, so the timestamp granularity monitor should as well.
Unfortunately, we currently get nanosecond ctime from Linux, but then only return millis from FileStatus, so this doesn't change the accuracy of the monitor at all.
PiperOrigin-RevId: 184536539
|
|
|
|
|
|
|
| |
rule for the execution statistics path.
RELNOTES: None.
PiperOrigin-RevId: 184534589
|
|
|
|
|
|
| |
Closes #4489.
PiperOrigin-RevId: 184532916
|
|
|
|
|
|
|
| |
Fix the create_main_dex_list stub script to find the dx jar binary correctly.
RELNOTES: None
PiperOrigin-RevId: 184532530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
child of the process where the Blaze client itself was run.
Limitations:
- Untested on Windows; it should work because ExecuteProgram() is implemented there, too, but since Windows doesn't support exec(), there is at least one process in between
Progress towards #2815.
RELNOTES[NEW]: The new "--direct_run" flag on "blaze run" lets one run interactive binaries.
PiperOrigin-RevId: 184528845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Causes Blaze to crash when building Exoblaze as shown in b/72936965.
Confirmed as root cause by rolling back this CL, building a Blaze
from HEAD, and successfully using it to build Exoblaze.
*** Original change description ***
C++: Remove last instatiation of CppModel outside CcLibraryHelper.
RELNOTES:none
PiperOrigin-RevId: 184528551
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184518931
|
|
|
|
|
|
|
|
| |
This is a rather small change to a Python tool used to produce a SHA256 hash. Currently, the whole file is loaded in memory before computing the hash, which causes problem when large files are processed. For instance, github.com/bazelbuild/rules_docker uses it to compute the hash of Docker images, which can be multiple GB in size. This PR avoids the tool to cause issues in a limited-memory environment.
Closes #4243.
PiperOrigin-RevId: 184518900
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also update the Python stub script template to set
$RUNFILES_MANIFEST_FILE or $RUNFILES_DIR so the
runfiles library only needs to look for those.
See https://github.com/bazelbuild/bazel/issues/4460
RELNOTES[NEW]: python,runfiles: You can now depend on `@bazel_tools//tools/runfiles:py-runfiles` to get a platform-independent runfiles library for Python. See DocString of https://github.com/bazelbuild/bazel/blob/master/src/tools/runfiles/runfiles.py for usage information.
Change-Id: I4f68a11cb59f2782e5203e39fe60cc66b46023a2
PiperOrigin-RevId: 184515490
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 184510731
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184498836
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184492828
|
|
|
|
|
|
|
|
|
| |
Add docs for the --workspace_status_command flag.
Fixes https://github.com/bazelbuild/bazel/issues/4220
RELNOTES: none
PiperOrigin-RevId: 184492241
|