aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime
Commit message (Collapse)AuthorAge
* 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
* Remove redundant words in logging message.Gravatar nharmata2017-12-08
| | | | | RELNOTES: None PiperOrigin-RevId: 178407067
* Change flag name --start_type to --start, to be consistent with adb options ↵Gravatar Googler2017-12-07
| | | | | | | | | flag. Add check to test options, default value of testFilter is null. RELNOTES: None PiperOrigin-RevId: 178337368
* Make ProcessWrapperUtil aware of the execution statistics file, and add new ↵Gravatar ruperts2017-12-05
| | | | | | | ExecutionStatisticsProvider. RELNOTES: None. PiperOrigin-RevId: 178056182
* Clarify bazel clean's options.Gravatar ccalvarin2017-12-04
| | | | | | | | | | Basically a refactor of https://github.com/bazelbuild/bazel/pull/2053, which separated the concepts of async and expunge but kept them intertwined at the option level. This was confusing to a number of users. The standard interface is to use one of --expunge, --async, or --expunge_async. --clean_style was more verbose and added no value, so can be removed. The contents of actuallyClean() could use some ... actual cleaning. This CL just changes the options, removing some of the artificial option-related complexity. RELNOTES[INC]: --clean_style is no longer an option. PiperOrigin-RevId: 177843049
* Change Bazel's default hash function to SHA256. Fixes #3193Gravatar buchgr2017-12-03
| | | | | | | RELNOTES: Bazel's default hash function was changed from MD5 to SHA256. In particular, this affects users of remote caching and execution, as all hashes will be SHA256 by default. PiperOrigin-RevId: 177740702
* Forward test relevant flags to mobile-install launcher.Gravatar Googler2017-12-01
| | | | | | | | Add new flag to specify the adb device serial number (--device). Change ..._mi/launcher.sh to ..._mi/launcher (see unknown commit). RELNOTES: None PiperOrigin-RevId: 177662635
* Refactor the FileSystem API to allow for different hash functions.Gravatar buchgr2017-11-30
| | | | | | | | | | | | | Refactor the FileSystem class to include the hash function as an instance field. This allows us to have a different hash function per FileSystem and removes technical debt, as currently that's somewhat accomplished by a horrible hack that has a static method to set the hash function for all FileSystem instances. The FileSystem's default hash function remains MD5. RELNOTES: None PiperOrigin-RevId: 177479772
* Buffer blaze queryGravatar ulfjack2017-11-30
| | | | | | | | | | | It was previously sending each label individually over gRPC, where each call has a lot of overhead. This makes queries with a large amount of output _a lot_ faster. For an example query where all packages are already loaded, I observe a difference of ~3.5s before this change to ~1.6s after this change. PiperOrigin-RevId: 177426957
* Add a CommandLineBuilder for the process-wrapper embedded tool, and use it ↵Gravatar ruperts2017-11-30
| | | | | | | | | everywhere instead of duplicating process-wrapper --shell_arguments in Blaze. To avoid a cyclic dependency, I broke up exec/local:local into exec/local:local and exec/local:options. RELNOTES: None. PiperOrigin-RevId: 177419268
* Add ActionKeyContext to Action#getKey.Gravatar tomlu2017-11-29
| | | | | | | This key context can be used by actions to share partial key computations, for instance when computing MD5s for nested sets. RELNOTES: None PiperOrigin-RevId: 177359607
* Remove the concept of a mandatory input which is allowed to be missing.Gravatar Googler2017-11-29
| | | | | RELNOTES: None. PiperOrigin-RevId: 177332323
* Update PathPackageLocator to take a list of potential build file names,Gravatar John Cater2017-11-28
| | | | | | | | | | | | | | instead of assuming BUILD. - Default the list to the same value as PackageLookupFunction: BUILD.bazel, BUILD. - Move BuildFileNames to the packages package, so it is more generally available. Part of #4056. Change-Id: Ie12512b492cd7d47a9e56ec3bc209f829feaf4b5 PiperOrigin-RevId: 177261295
* Remove process-wrapper duplication from RunCommand.Gravatar ruperts2017-11-28
| | | | | | | Also rename ProcessWrapperRunner to ProcessWrapperUtil, since it isn't really a Runner (it doesn't run anything). RELNOTES: None. PiperOrigin-RevId: 177260951
* Document Android options.Gravatar ajmichael2017-11-28
| | | | | RELNOTES: None PiperOrigin-RevId: 177195468
* Print 'waiting for other blaze command' on its own line.Gravatar Googler2017-11-28
| | | | | | | | | | It now prints a newline char immediately, rather than waiting until the lock is released, and printing 'done!' at the end of the line. This allows per-line parsers (like IntelliJ) to display this progress notification without special-case hacks. PiperOrigin-RevId: 177180918
* Remove unused flag.Gravatar Googler2017-11-27
| | | | | RELNOTES: None. PiperOrigin-RevId: 177113477
* Moving the location of the mobile-install launch script.Gravatar Googler2017-11-21
| | | | | | | | Working on consolidating all mobile-install artifacts under label.name + "_mi/" directory. RELNOTES:None. PiperOrigin-RevId: 176592620
* UI: reset timer on every status/strategy changeGravatar Klaus Aehlig2017-11-21
| | | | | | | | | | | | | For an action, whenever the status or strategy changes, reset the timer. In this way, we show the time an action spent in the current state, rather than the total time the action spent since started. This might give a better picture of what is currently going on in the system. Fixes #4089. Change-Id: I441337cf2eec58702889ac7a6a9ed150708e8c9d PiperOrigin-RevId: 176497486
* UI: distinguish executing actionsGravatar Klaus Aehlig2017-11-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When showing the current actions, the most interesting are those that are currently being executed, not those that are waiting for resources or otherwise in the process of being scheduled. Therefore, show the executing actions at the top of the list. Also add more visual hints to distinguish executing from non executing actions. Screenshot (14:51:21) [160 / 230] 32 actions, 11 running Compiling lotsofwork/true986.c; 0s linux-sandbox Compiling lotsofwork/true982.c; 0s linux-sandbox Compiling lotsofwork/true983.c; 0s linux-sandbox Executing genrule //lotsofwork:true975_c; 0s linux-sandbox Compiling lotsofwork/true981.c; 0s linux-sandbox Linking lotsofwork/true_999; 0s linux-sandbox Linking lotsofwork/true_996; 0s linux-sandbox Linking lotsofwork/true_998; 0s linux-sandbox Compiling lotsofwork/true980.c; 0s linux-sandbox Compiling lotsofwork/true98.c; 0s linux-sandbox Executing genrule //lotsofwork:true974_c; 0s linux-sandbox [Sched] Creating runfiles tree bazel-out/k8-fastbuild/bin/lotsofwork/true_974.runfiles [Sched] Linking lotsofwork/true_997 [Sched] Linking lotsofwork/true_995 [Sched] Linking lotsofwork/true_99 [Sched] Linking lotsofwork/true_991 ... Improves on #4089. Change-Id: I1bc6636d5e53a16151023bba595e38259eb1ac88 PiperOrigin-RevId: 176483192
* Add warning for configs that are expanded multiple times.Gravatar ccalvarin2017-11-20
| | | | | | | Some flags are relatively immune to repeated mentions, since only the last mention ends up mattering, but in some cases, the values are accumulated. Expanding the same config twice may lead to surprising results, so provide a friendly warning. RELNOTES: None PiperOrigin-RevId: 176422758
* Add warning for long chain of recursive --configs.Gravatar ccalvarin2017-11-20
| | | | | | | Configs are recursive, but let's be reasonable. If there's an absurdly long list of configs inheritance, warn about it. It is probably unnecessary, and might very well be unintentional and surprising to the user. RELNOTES: None. PiperOrigin-RevId: 176405183
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-10 01:37:13 +0000