| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
| |
Fixes: 2846
RELNOTES: Bazel now displays information about remote cache hits and execution strategies used in its UI after every build and test, and adds a corresponding line "process stats" to BuildToolLogs in BEP.
PiperOrigin-RevId: 191441770
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 191354727
|
|
|
|
|
|
| |
The BuildEventStreamer was checking the command name for the exact string "test" for test-specific handling, even though coverage is also a test command.
PiperOrigin-RevId: 191137755
|
|
|
|
|
|
|
| |
String categories are deprecated, replace this special-cased value with a specific OptionMetadata tag, TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES.
RELNOTES: None.
PiperOrigin-RevId: 191069412
|
|
|
|
|
|
|
|
|
|
|
| |
We expect that the client passes all startup options to the server, default or explicit. The server's listing of default values should not matter. Yet for a number of these options, the default value in the server was relied upon, because the server command line was not constructed with the client's default value included. Fix visible cases of this, long term this should be tested for, so the invariant is not broken again.
This has been the documented expectation for a long time, but a number of violations have crept up over time. Update the comments that lead to this expectation to be more realistic.
Add debug statement that shows which options are changed when startup options cause the server to be restarted. The detailed logs will only be seen if --client_debug is set to TRUE.
RELNOTES: None.
PiperOrigin-RevId: 191066983
|
|
|
|
| |
PiperOrigin-RevId: 190779535
|
|
|
|
|
|
|
|
|
| |
These have all had a chance to be categorized with the OptionDocumentationCategory enum, and the help output already uses the enum-grouped format.
The "incompatible changes" category has meaning for --all_incompatible_changes and will be removed separately.
RELNOTES: None.
PiperOrigin-RevId: 190773778
|
|
|
|
|
|
| |
ConfiguredTarget#getConfiguration(). Add convenience methods in four Java test classes for use by refactoring tools to do this#getConfiguration(ConfiguredTarget) instead of ConfiguredTarget#getConfiguration.
PiperOrigin-RevId: 190684008
|
|
|
|
|
|
| |
cquery output callback logic
PiperOrigin-RevId: 190667120
|
|
|
|
|
|
|
| |
In preparation for removing all uses of the category field in Bazel options.
RELNOTES: None.
PiperOrigin-RevId: 190665669
|
|
|
|
|
|
| |
most elegant solution, but I don't have a better idea.
PiperOrigin-RevId: 190656869
|
|
|
|
|
|
| |
ConfiguredTargetAndData into TargetCompleteEvent, which seems reasonable.
PiperOrigin-RevId: 190634162
|
|
|
|
|
|
|
|
| |
methods, TransitiveInfoCollection#getConfigurationKey() and ConfiguredTarget#getConfigurationChecksum(). These methods currently delegate to #getConfiguration(), but in the future they won't. I hope to get rid of #getConfigurationChecksum(), but I may have to fold the checksum into BuildConfigurationValue.Key or leave it as a separate field in ConfiguredTarget.
Transform a representative (random?) selection of #getConfiguration calls, to show that it's pretty much possible everywhere.
PiperOrigin-RevId: 190474978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The number of stat() syscalls in the SymlinkedSandboxedSpawn was way too high. Do less, feel better.
- When using --experimental_sandbox_base, ensure that symlinks in the path are resolved. Before this, you had to check whether on your system /dev/shm is a symlink to /run/shm and then use that instead. Now it no longer matters, as symlinks are resolved.
- Remove an unnecessary directory creation from each sandboxed invocation. Turns out that the "tmpdir" that we created was no longer used after some changes to Bazel's TMPDIR handling.
- Use simpler sandbox paths, by using the unique ID for each Spawn provided by SpawnExecutionPolicy instead of a randomly generated temp folder name. This also saves a round-trip from our VFS to NIO and back. Clean up the sandbox base before each build to ensure that the unique IDs are actually unique. ;)
- Use Java 8's Process#isAlive to check whether a process is alive instead of trying to get the exitcode and catching an exception.
Closes #4913.
PiperOrigin-RevId: 190472170
|
|
|
|
|
|
|
| |
tests, too.
RELNOTES: None.
PiperOrigin-RevId: 190439262
|
|
|
|
|
|
|
| |
This mimics "--nodirect_run". Apparently, a lot of people depend on this :(
RELNOTES: None.
PiperOrigin-RevId: 190433808
|
|
|
|
|
|
|
|
|
| |
overwrite the environment of their caller.
Admittedly, doing that was a bad idea in the first place.
RELNOTES: None.
PiperOrigin-RevId: 190430189
|
|
|
|
|
|
| |
in either a FULL or LITE version. Trigger new output with the new --transitions cquery flag in the new CqueryOptions class.
PiperOrigin-RevId: 190278664
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove Optional<> where it's not needed. It's nice for return values, but IMHO it was overused in this code (e.g. Optional<List<X>> is an anti-pattern, as the list itself can already signal that it is empty).
- Use Bazel's own Path class when dealing with paths, not String or java.io.File.
- Move LinuxSandboxUtil into the "sandbox" package.
- Remove dead code and unused fields.
- Migrate deprecated VFS method calls to their replacements.
- Fix a bug in ExecutionStatistics where a FileInputStream was not closed.
Closes #4868.
PiperOrigin-RevId: 190217476
|
|
|
|
|
|
|
| |
DirectTargetProvider works with WalkableGraph directly. If it fails to find target, then last try to use delegate TargetProvider which supposed to be PackageManager from SkyframeExecutor.
RELNOTES:none
PiperOrigin-RevId: 190204106
|
|
|
|
|
|
|
| |
vardef().
RELNOTES: None.
PiperOrigin-RevId: 190196933
|
|
|
|
|
|
| |
from the provided defaults in Options classes. These are used to create BuildOptionsDiffForReconstruction, which lets us store only the diffs in our BuildConfigurationValue.Keys.
PiperOrigin-RevId: 190117455
|
|
|
|
|
|
|
| |
@SkylarkSignature
RELNOTES: None.
PiperOrigin-RevId: 190073508
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 190046225
|
|
|
|
|
|
|
|
|
| |
We are still unable to turn this on to write to files, but there are currently 2 logging systems in use in the client: the inactive one, and the print-to-stderr option triggered by --client_debug. Combine these, so we can use the same logging format for both.
Also combine it with the VerboseLogging functionality - it was not documented anywhere and seems redundant.
RELNOTES: None.
PiperOrigin-RevId: 189979051
|
|
|
|
|
|
|
| |
It is no longer meaningful since the vfs doesn't have an internal path tree to dump.
RELNOTES: Remove support for blaze dump --vfs. It is no longer meaningful.
PiperOrigin-RevId: 188739379
|
|
|
|
|
|
|
|
|
| |
Unlike in fixed-point (legacy) expansion of configs, with --expand_configs_in_place we do not use the options parser to parse each config-definition default override - we first find the full expansion and then expand it in place of the original --config=value instance. For this reason though, we don't support space-separation of recursive configs and their values.
The old warning for this was confusing though, and did not provide much guidance. This should be better, now the warning specifies which config is malformed, in what file, and that it expects the "=" character.
RELNOTES: None.
PiperOrigin-RevId: 188509060
|
|
|
|
| |
PiperOrigin-RevId: 188212286
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 188179200
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 188164754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was previously assumed that safety wasn't needed because
1) all builtins should be registered in static initializer blocks, and
2) all retrievals should occur during Skylark evaluation, after static initialization completes.
It turns out these assumptions aren't actually true (Who would've thunk it!). SkylarkActionFactory has been observed to be initialized as late as analysis time, and retrievals occur as early as constructing a PackageFactory (when scanning the native module). The failure mode is particularly ugly: Random Skylark method lookups will fail non-deterministically.
This change guards against this by making the builtins registry implement a form of freezing. Before freezing, reads and writes are allowed and are synchronized. After freezing, only reads are allowed and they are unsynchronized for performance. BlazeRuntime is responsible for flipping the bit, and for ensuring classes like SkylarkActionFactory run their initialization by that point. Unit tests don't need to worry, since they just stay unfrozen and synchronized throughout.
RELNOTES: None
PiperOrigin-RevId: 188080136
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 187974423
|
|
|
|
|
|
|
| |
published via the BEP, instead of only publishing failed actions and extra actions.
RELNOTES: Add a --build_event_publish_all_actions flag to allow all actions to be published via the BEP.
PiperOrigin-RevId: 187683799
|
|
|
|
|
| |
RELNOTES: Use bazel dump --action_graph=/path/to/action.proto --action_graph:targets://foo:bar,//foo:foo to filter for certain targets in the action graph dump.
PiperOrigin-RevId: 187608321
|
|
|
|
|
|
| |
the end of the build in an effort to get an accurate measurement of used memory.
PiperOrigin-RevId: 187337487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular:
- Make it support --script_path
- Make it add command line arguments specified on the command line to tests
- Remove a stale comment
This introduces the following differences in behavior wrt. --nodirect_run:
- Tests are run through the test setup script and get the environment variables specific to tests
- --test_arg arguments will be on the command line of test targets
- The script written by --script_path overwrites the environment of the binary with the client environment at the time of "blaze run" (for binaries) or the proper test environment (for tests)
RELNOTES: None.
PiperOrigin-RevId: 187309437
|
|
|
|
|
|
|
|
|
|
|
| |
...so that it can use that path to compute other directories in the
output user base, in particular the default location for caches.
The first cache we will add is the hash-index cache for downloads
of external archives, but a spawn cache might be added later in the
output user base as well.
Change-Id: I24b1c33235c8f76ec008ecb1789163de2b2a45be
PiperOrigin-RevId: 187164275
|
|
|
|
|
|
|
| |
See https://blog.bazel.build/2018/01/19/config-parsing-order.html for context on this change.
RELNOTES: --config flags now expand in place by default.
PiperOrigin-RevId: 186831701
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 186658512
|
|
|
|
|
|
|
|
| |
These may be reused by configured query, so rather move it early before
consumers starts depending on the old name.
RELNOTES: None
PiperOrigin-RevId: 186633754
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this dumps the current state in skyframe (which may contain more nodes than you're interested in):
- bazel build --nobuild //interesting:targets
- bazel dump --action_graph=/path/to/file
- printproto --proto2 --raw_protocol_buffer --message=action_graph.ActionGraphContainer --multiline --proto=third_party/bazel/src/main/protobuf/action_graph.proto /path/to/file
We'll add filtering options in a later CL.
RELNOTES[NEW]: Add option to dump the action graph to a file: 'bazel dump --action_graph=/path/to/file'.
PiperOrigin-RevId: 186597930
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 186513938
|
|
|
|
|
|
|
| |
This is in preparation for migrating to the new way of specifying providers as described in[]
RELNOTES:none
PiperOrigin-RevId: 186436462
|
|
|
|
|
|
|
|
|
| |
lib.analysis.actions -> lib.actions.
These are fundamental types that want to sit alongside types like Spawn.
RELNOTES: None
PiperOrigin-RevId: 185887971
|
|
|
|
|
|
|
| |
It's never used during analysis, it shouldn't be used during analysis, so let's
not make it available during analysis.
PiperOrigin-RevId: 185808384
|
|
|
|
|
|
|
| |
expr - the expression to be evaluated
word - the configuration (represented by the strings 'host', 'target', or 'null') to try to find the result(s) of 'expr' in. If some but not all results of expr can be found in the specified config, then the subset that can be is returned. If no results of expr can be found in the specified config, then an error is thrown.
PiperOrigin-RevId: 185572590
|
|
|
|
|
|
|
|
|
|
| |
"blaze run --direct_run" so that the called binary knows about the working directory the client was called from.
Its cwd is its runfiles directory and if not for the fact that we have to convey *two* directories to it, I'd have considered changing that. As it is, however, we can't convey two directories with the cwd of the binary so we have to use environment variables.
RELNOTES[NEW]: "blaze run --direct_run" now exports the BUILD_{WORKSPACE,WORKING}_DIRECTORY variables to tell the binary about the cwd of the client and the workspace root.
PiperOrigin-RevId: 185515884
|
|
|
|
| |
PiperOrigin-RevId: 185441432
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExperimentalEventHandler is in charge of composing the pretty progress bar
that Bazel displays. This progress bar is a multi-line message with control
characters printed on the terminal.
The progress bar was composed by issuing many individual writes to an
AnsiTerminal. Because the AnsiTerminal in this case was backed by an error
stream (which are unbuffered), each of these writes resulted in a gRPC to
the Bazel client to write the message to the console. gRPC calls are much
more expensive than calls to a file descriptor, and, in general, even small
writes to a file descriptor should be avoided when preparing long messages.
To fix this, fully buffer the output messages sent to the AnsiTerminal until
explicitly flushed. ExperimentalEventHandler was already doing the right
thing regarding flushes but did not account for the fact that each write
would be (unintentionally) sent directly to the terminal.
The flicker was significant: on a pathological case (building sandboxfs with
Bazel on my MacBook Pro 13" on macOS), this change shaves about 5 seconds of
build time on the previous 45 second-long build. I think this only happened
with "bazel run" and "bazel test" invocations and not "bazel build", but
I haven't really confirmed this.
RELNOTES: None.
PiperOrigin-RevId: 185405892
|
| |
|