aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime
Commit message (Collapse)AuthorAge
* Add the BUILD_WORKSPACE_DIRECTORY and BUILD_WORKING_DIRECTORY variables to ↵Gravatar lberki2018-02-13
| | | | | | | | | | "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
* Get rid of some uses of RuleConfiguredTarget.getAttributeMapper().Gravatar mjhalupka2018-02-12
| | | | PiperOrigin-RevId: 185441432
* Fix screen flicker caused by small writes.Gravatar jmmv2018-02-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PiperOrigin-RevId: 185383460Gravatar juliexxia2018-02-12
|
* Remove hard-wired basenames for the test setup and the coverage collection ↵Gravatar lberki2018-02-09
| | | | | | | | | script. Accomplished by creating an explicit attribute for both of them on test actions. RELNOTES: None. PiperOrigin-RevId: 185132460
* Replace path implementation.Gravatar tomlu2018-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Path and PathFragment have been replaced with String-based implementations. They are pretty similar, but each method is dissimilar enough that I did not feel sharing code was appropriate. A summary of changes: PATH ==== * Subsumes LocalPath (deleted, its tests repurposed) * Use a simple string to back Path * Path instances are no longer interned; Reference equality will no longer work * Always normalized (same as before) * Some operations will now be slower, like instance compares (which were previously just a reference check) * Multiple identical paths will now consume more memory since they are not interned PATH FRAGMENT ============= * Use a simple string to back PathFragment * No more segment arrays with interned strings * Always normalized * Remove isNormalized * Replace some isNormalizied uses with containsUpLevelReferences() to check if path fragments try to escape their scope * To check if user input is normalized, supply static methods on PathFragment to validate the string before constructing a PathFragment * Because PathFragments are always normalized, we have to replace checks for literal "." from PathFragment#getPathString to PathFragment#getSafePathString. The latter returns "." for the empty string. * The previous implementation supported efficient segment semantics (segment count, iterating over segments). This is now expensive since we do longer have a segment array. ARTIFACT ======== * Remove Path instance. It is instead dynamically constructed on request. This is necessary to avoid this CL becoming a memory regression. RELNOTES: None PiperOrigin-RevId: 185062932
* Remove references to getTarget(). Requires threading through anGravatar mjhalupka2018-02-08
| | | | | | | ExtendedEventHandler so we can get the target via the package manager during rule dumps. PiperOrigin-RevId: 185042522
* Remove another getTarget() call from PrintActionCommand.Gravatar mjhalupka2018-02-08
| | | | PiperOrigin-RevId: 185006324
* Refactor RunCommand so that it's a bit less messy.Gravatar lberki2018-02-08
| | | | | RELNOTES: None. PiperOrigin-RevId: 184996540
* Give a reasonable environment for tests run by "blaze run --direct_run".Gravatar lberki2018-02-08
| | | | | | | | | | | | It's not entirely correct, but almost. The code in RunCommand becomes somewhat more confusing. Cleanup change incoming. Fixes #2815. RELNOTES[INC]: "blaze run --direct_run" with tests now gives the test an approximation of the official test environment. PiperOrigin-RevId: 184992651
* BEP: ensure that TestAttempts are reported after their targetGravatar Klaus Aehlig2018-02-07
| | | | | | | | | | Ensure that each test attempt is only reported after the report of the completion of the build of the corresponding test target. Normally this should happen anyway, but due to races on the internal event bus, the order of the report might be messed up. So add an explicit order constraint. Change-Id: I4d325bc31a46dcdf8763ba5416b5135a0978536e PiperOrigin-RevId: 184825306
* Delete the now-useless interfaces ServerCommand and CommandExecutor.Gravatar lberki2018-02-06
| | | | | | | | | 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
* Move BlazeRuntime/BlazeCommandDispatcher shutdown to where they are created.Gravatar lberki2018-02-06
| | | | | RELNOTES: None. PiperOrigin-RevId: 184692000
* Remove ShutdownBlazeServerException in favor of indicating that the server ↵Gravatar lberki2018-02-06
| | | | | | | should be shut down in BlazeCommandResult. RELNOTES: None. PiperOrigin-RevId: 184678994
* Add a "direct" mode to "blaze run" that makes the process being run a directGravatar lberki2018-02-05
| | | | | | | | | | | | | | 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
* Support explicitly specifying a location for jvm.outGravatar michajlo2018-01-29
| | | | | | | | Allows users to monitor server output without needing to fish the output base. Windows support is copied more or less verbatim from recommendations, I unfortunately don't know how to test this on windows. PiperOrigin-RevId: 183674130
* Move BazelRuleClassProvider.TESTING_SUPPORT to its own class in rules/test.Gravatar lpino2018-01-29
| | | | PiperOrigin-RevId: 183672444
* Remove a ConfiguredTarget.getTarget() call in PrintActionCommand.Gravatar mjhalupka2018-01-26
| | | | PiperOrigin-RevId: 183416882
* Remove ConfiguredTarget.getTarget() from RunCommand. Replace it with gettingGravatar mjhalupka2018-01-26
| | | | | | target from CommandEnvironment. PiperOrigin-RevId: 183416006
* PiperOrigin-RevId: 183094604Gravatar ajmichael2018-01-24
|
* Use the new option categories by defaultGravatar ccalvarin2018-01-22
| | | | | | | | | Bazel help output will now use the new categories by default, including for the generated html documentation at https://bazel.build/versions/master/docs/command-line-reference.html Issue #3758 - this switches to the new categories, but the grouping is still by command, which leads to duplicate options RELNOTES: None PiperOrigin-RevId: 182815006
* Add option to optionally wipe state at the end of a build.Gravatar ccalvarin2018-01-22
| | | | | | | This will serve as an alternative to --batch, leaving behind a server without state from the previous build. RELNOTES: Introduces --[no]keep_state_after_build PiperOrigin-RevId: 182778500
* Move storage of queryExpression for cquery out of BuildRequest and straight ↵Gravatar juliexxia2018-01-19
| | | | | | into processRequest method in BuildTool. This is an extension of CL/181816980 and prevents pollution of BuildRequest. PiperOrigin-RevId: 182576704
* Introduce Root class.Gravatar tomlu2018-01-17
| | | | | | | | | | | This class represents a root (such as a package path or an output root) used for file lookups and artifacts. It is meant to be as opaque as possible in order to hide the user's environment from sky keys and sky functions. Roots are used by RootedPaths and ArtifactRoots. This CL attempts to make the minimum number of modifications necessary to change RootedPath and ArtifactRoot to use these fields. Deprecated methods and invasive accessors are permitted to minimise the risk of any observable changes. RELNOTES: None PiperOrigin-RevId: 182271759
* Add deprecation warning message to mobile-install classic mode.Gravatar Googler2018-01-17
| | | | | | | | | We've notified the top classic users by email that classic mode is deprecated. As we are no longer actively supporting classic mode, we'd like users to move over to skylark. RELNOTES: None. PiperOrigin-RevId: 182268733
* Introduce the blaze cquery command as the new ui for configurable query.Gravatar juliexxia2018-01-12
| | | | | | | | | | | | | | | | | | before: blaze build --nobuild //foo --experimental_post_build_query="deps(//foo)" after: blaze cquery "deps(//foo)" pros of ui change: - more concise - assumes query expression targets == targets to be built (but allows for flexibility through --top_level_targets flag) - separate from build command - cquery command recognizes query options, build options, and its own unique set of options cons of ui change: - adds another command to blaze - recognizes options that don't actually work yet -> requires more option validation RELNOTES: None PiperOrigin-RevId: 181816980
* Simplify root relative path calculation.Gravatar tomlu2018-01-12
| | | | | | This is a first-class artifact concept. No need to go the long way to get this path. PiperOrigin-RevId: 181717016
* BuildEventStreamer: ingore noop-flush()sGravatar Klaus Aehlig2018-01-11
| | | | | | | | | | | | The BuildEventStreamer supports a method flush() to report any pending stdout/stderr in the BEP; in particular, all internal buffers of for those streams are cleared (and the memory can be reclaimed). If there are no pending bytes in those streams, however, there is no need to generate an additional progress event to get rid of the buffered stream contents. Make flush() a no-op in this case. Change-Id: Ia8cf8733fdeaf4d1a50488736d2637862e7cb4f5 PiperOrigin-RevId: 181590982
* BEP: make stdout/stderr buffering configurableGravatar Klaus Aehlig2018-01-11
| | | | | | | | | | For different applications, different size of buffered stdout/stderr might be acceptable; essentially it is a trade off between latency and number of messages generated. Put this trade off into the control of the user by adding an appropriate flag. Change-Id: I8fb4d19a336205fa28d01340f2f0b2be9b4a24f3 PiperOrigin-RevId: 181570242
* Rework implementation of --nobuild_runfile_manifests.Gravatar Benjamin Peterson2018-01-03
| | | | | | | | | | | | | When --nobuild_runfile_manifests is passed, don't create runfiles input or output manifests at all. This seems better than creating fake manifest artifacts that are actually a middleman. Fail fast for local tests and the run command when --nobuild_runfiles_manifests is passed. (These cases were failing with obscure errors before under --nobuild_runfile_manifests-I just improved the messaging. See https://github.com/bazelbuild/bazel/issues/4177.) Change-Id: I351d26f746ecbe47016b58e4662768a5b6a72ff2 PiperOrigin-RevId: 180659571
* PiperOrigin-RevId: 179941785Gravatar Googler2017-12-22
|
* PiperOrigin-RevId: 179932935Gravatar ajmichael2017-12-22
|
* "Blaze" -> "Bazel" in message visible on CLIGravatar Chris Beach2017-12-22
| | | | | | | | | | | | Example message containing "Blaze" - should be "Bazel": $ bazel run //... ERROR: Blaze can only run a single target. Do not use wildcards that match more than one target. INFO: Elapsed time: 0.092s Closes #3665. PiperOrigin-RevId: 179921748
* Warn about config expansions as we do for other expansions.Gravatar ccalvarin2017-12-21
| | | | | | | | | If an expanded value overrides an explicit value, users who do not know the contents of the expansion may be surprised. We already warned about this for hard-coded expansions, and this is now applicable for --config expansions as well. This will only warn when a single-valued option has its value replaced. Options that accumulate multiple values in a list (e.g., --copt) will silently include both explicit and expanded values. RELNOTES: None. PiperOrigin-RevId: 179857526
* Consolidate instances of the --loading_phase_threads flag.Gravatar juliexxia2017-12-21
| | | | | RELNOTES: None. PiperOrigin-RevId: 179838936
* Move compulsory ProcessWrapperUtil parameters into its builder() method, to ↵Gravatar ruperts2017-12-20
| | | | | | | be consistent with LinuxSandboxUtil. RELNOTES: None. PiperOrigin-RevId: 179758847
* Get rid of LabelAndConfiguration class: ConfiguredTargetKey contains the ↵Gravatar janakr2017-12-20
| | | | | | same information and is more useful, since it's practically a SkyKey. PiperOrigin-RevId: 179727105
* Use linux-sandbox via the (new) LinuxSandboxUtil. (second attempt).Gravatar ruperts2017-12-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 179705357
* Automated rollback of commit 52b62164af031c50b7a0584303caad67af5e1d4d.Gravatar aehlig2017-12-20
| | | | | | | | | | | | | *** Reason for rollback *** Breaks //src/test/shell/bazel:bazel_sandboxing_test *** Original change description *** Use linux-sandbox via the (new) LinuxSandboxUtil. RELNOTES: None. PiperOrigin-RevId: 179676894
* Use linux-sandbox via the (new) LinuxSandboxUtil.Gravatar ruperts2017-12-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 179646155
* Remove wrapper options support.Gravatar ccalvarin2017-12-19
| | | | | RELNOTES: None. PiperOrigin-RevId: 179588174
* Consolidate instances of the --keep_going flag.Gravatar juliexxia2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179468685
* Don't suggest using bazel clean --async when it's unsupportedGravatar Akira Baruah2017-12-15
| | | | | | | Fixes #4176 (https://github.com/bazelbuild/bazel/issues/4176). Closes #4236. PiperOrigin-RevId: 179218605
* Rename --keep_incrementality_data to --track_incremental_state.Gravatar ccalvarin2017-12-14
| | | | | | | | | New name clears the namespace a 2nd flag that will wipe the build graph after the build. The old name would be confusing as it could easily apply to that, and so needs to be more specifically just about tracking state in the first place. The new flag can be clearly separate and about keeping state after the build. Partial roll forward of https://github.com/bazelbuild/bazel/commit/9321316b34767b06c3071b2cf2a4de189874fcce, with fixes to documentation that are still relevant. RELNOTES: Rename --keep_incrementality_data to --track_incremental_state PiperOrigin-RevId: 179078292
* Accept build IDs by flag. (Rollforward of ↵Gravatar ccalvarin2017-12-14
| | | | | | | | | | | | | https://github.com/bazelbuild/bazel/commit/c6b6dbadd0a93936c51154b25abc5fbba8f2d1af) We accepted these by environment variable largely because setting it via invocation policy would require changing invocation policy for each command, which had caused the Bazel server to restart, loosing incremental state. This is fixed: changing invocation policy no longer causes Bazel to restart its servers, so accept these as normal options. We will soon no longer accept these flags by environment variable, but will accept both for a transition period, so that nobody relying on these values is broken by a single release. To inform users of this environment variable, anyone setting the environment variable without the flag will receive a warning but the value will be kept. The following release will no longer accept an environment variable. Note on format: invocation_id we accept only clean UUIDs, but for build_request_id, to help differentiate otherwise undifferentiable id types, we accept arbitrary prefixes before the UUID. The user is responsible for picking prefixes that are sane. RELNOTES: None. PiperOrigin-RevId: 179063120
* Properly capitalize Build Event Protocol in Blaze output for consistency.Gravatar jingwen2017-12-14
| | | | | | | | | | | | | | | | | Before: ____Waiting for build event protocol upload: 0s ____Waiting for Build Event Protocol upload to finish. ____Build Event Protocol upload finished successfully. After: ____Waiting for Build Event Protocol upload: 0s ____Waiting for Build Event Protocol upload to finish. ____Build Event Protocol upload finished successfully. RELNOTES: None. PiperOrigin-RevId: 179049827
* Rename OutputGroupProvider -> OutputGroupInfo.Gravatar dslomov2017-12-14
| | | | | RELNOTES: None PiperOrigin-RevId: 179046403
* Automatic code cleanup.Gravatar Googler2017-12-14
| | | | PiperOrigin-RevId: 179042182
* Automated rollback of commit 9321316b34767b06c3071b2cf2a4de189874fcce.Gravatar ccalvarin2017-12-11
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Design change, 2 boolean flags instead of 1 enum flag *** Original change description *** Add --incremental_state_retention_strategy This option is intended to replace some of the uses of --batch. It lets users specify that builds should not be incremental, and how eagerly to discard the state that is kept around for incrementality. Note that for both values discard_eargerly and keep_for_life_of_build, the build graph is kept around until the next build. This may change. Will add tests for keep_for_life_of_build in a later change, for now it will warn that that feature is experimen... *** ROLLBACK_OF=178661777 RELNOTES: None. PiperOrigin-RevId: 178681472
* Add --incremental_state_retention_strategyGravatar ccalvarin2017-12-11
| | | | | | | | | This option is intended to replace some of the uses of --batch. It lets users specify that builds should not be incremental, and how eagerly to discard the state that is kept around for incrementality. Note that for both values discard_eargerly and keep_for_life_of_build, the build graph is kept around until the next build. This may change. Will add tests for keep_for_life_of_build in a later change, for now it will warn that that feature is experimental. RELNOTES: --[no]keep_incrementality_data is gone, replaced by the enum-valued --incremental_state_retention_strategy PiperOrigin-RevId: 178661777
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-09 15:27:08 +0000