aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime
Commit message (Collapse)AuthorAge
* 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
* Change config expansion application order, gated by startup flag ↵Gravatar ccalvarin2017-11-20
| | | | | | | | | | | | | --expand_configs_in_place. --config options were expanded in a fix-point expansion, where in practice, the flags that --config values expanded to ended up between the normal bazelrc options and the command line's explicit options. Since the options parser has an order-based priority scheme and it accepts multiple mentions of a single-valued option, this conflicts with users' expectations of being able to override these config expansions by using the order in which they are mentioned. This change makes it possible to expand the config values defined in your bazelrc (or blazerc) files to occur in-place: --stuff --config=something --laterstuff will interpret the options that --config=something expands to as if they had been mentioned explicitly between --stuff and --laterstuff. In order to not break users relying on complex flag combinations to configure their builds, this behavior will not yet be turned on by default. Instead, use --expand_configs_in_place as a startup flag to test this feature. --announce_rc may be helpful for debugging any differences between the fixed point and in-place expansions. Once you've debugged your problems, add "startup --expand_configs_in_place" to your blazerc to stick to the new behavior. RELNOTES: Use --expand_configs_in_place as a startup argument to change the order in which --config expansions are interpreted. PiperOrigin-RevId: 176371289
* UI: show status instead of strategy for non-executing actionsGravatar Klaus Aehlig2017-11-15
| | | | | | | | | | | | | | Even if an action is planned to run and a strategy assigned, it does not mean it is actually executing; e.g., it might be waiting for local resources. To reduce confusion, show the status instead of the execution strategy for non-executing actions. Also avoid the word "running" for the total number of executing and scheduled to be executed actions. Improves on Issue #4089. Change-Id: If658c1a24ee26eb27ccd892847af18015355a8d3 PiperOrigin-RevId: 175818071
* BuildToolLogs: clean up interfaceGravatar aehlig2017-11-14
| | | | | | | | For build log files that are inlined, we eventually have to report ByteStrings, so avoid the detour through strings, potentially causing encoding issues. PiperOrigin-RevId: 175647576
* Remove extra spaceGravatar Googler2017-11-13
| | | | PiperOrigin-RevId: 175535010
* RELNOTES: --keep_incrementality_data flag allows Bazel servers to be run in ↵Gravatar janakr2017-11-12
| | | | | | | | | | | | | | memory-saving non-incremental mode independent of --batch and --discard_analysis_cache. A command run with --nokeep_incrementality_data will discard data that would be needed for incremental builds. Subsequent commands can be sent to the same server, but they will not get the benefit of incrementality from this command. However, if --keep_incrementality_data is specified on a subsequent command, the commands after that will get the benefits of incrementality. There are two benefits to not being dependent on --batch. First, this allows Bazel servers to be run in extreme memory-saving mode without the startup penalties (JVM startup, JITting) that --batch execution imposes. Second, this allows Bazel developers to inspect the state of a Bazel server after an extreme memory-saving build. In order to avoid discarding data unnecessarily (for instance, on a "bazel info used-heap-size-after-gc" or "bazel dump --skyframe=summary") the actual resetting of the graph is done lazily, right before its use in SequencedSkyframeExecutor#sync. This is morally a partial rollback of https://github.com/bazelbuild/bazel/commit/98cd82cbdcac7c48164a611c5a9aa8fc2f1720ef. For now, our tests specify all of the flags. After this change sticks, I plan to get rid of the --batch flag from these tests, which should allow for some clean-ups. Eventually --batch and --discard_analysis_cache may not imply that we don't keep incremental state: we can require that it be specified explicitly. PiperOrigin-RevId: 175335075
* Add option-specified warning.Gravatar ccalvarin2017-11-10
| | | | | | | Accept warnings specified by flag. This flag will cause a warning to be printed like a standard Option deprecation warning or any other warning from options parsing. This can be used to deprecate definitions of config expansion or bazelrc files. This should not be used to deprecate internal option specifications. RELNOTES: None. PiperOrigin-RevId: 175231963
* Make the config expansion behavior modular.Gravatar ccalvarin2017-11-10
| | | | | | | | | | | Reorganize the BlazeOptionHandler to make it easy to exchange out how the config options are expanded using the definitions in the blazerc. Also change the getOptionsMap call to actually structure the rc options in the order that we parse them: we expand them in command order (for the test command, first add all "common" options, then "build," then "test") and then within each command, we expand the options in the rc order. This somewhat simplifies the rc expansion code, and avoids the two-phase regrouping that used to happen. This change should not change the semantics of rc option ordering. A followup change will add an alternative implementation for --config's expansion. RELNOTES: None. PiperOrigin-RevId: 175208971
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* RELNOTES: Document interaction between test_suite and target exclusionsGravatar Googler2017-11-07
| | | | | | Now with more accuracy. PiperOrigin-RevId: 174873635
* Automated rollback of commit 0dffc49f528c4c6e641221060e41aa6896310bdf.Gravatar Googler2017-11-06
| | | | | | | | | | | *** Reason for rollback *** This doesn't seem to be correct. I was confused by an example where a target is excluded from being run, but still built. *** Original change description *** RELNOTES: Document interaction between test_suite and target exclusions PiperOrigin-RevId: 174536378
* Avoid crash when a test and its alias are specified on the command line for ↵Gravatar lberki2017-11-03
| | | | | | | "blaze test". RELNOTES: None. PiperOrigin-RevId: 174386473
* Pass build_id to mobile-install deploy scriptGravatar Googler2017-11-03
| | | | PiperOrigin-RevId: 174343502
* Fix typo in BlazeModule#blazeShutdown javadoc.Gravatar ajmichael2017-11-02
| | | | | RELNOTES: None PiperOrigin-RevId: 174229364
* Automated rollback of commit c6b6dbadd0a93936c51154b25abc5fbba8f2d1af.Gravatar janakr2017-10-31
| | | | | | | | Not a totally clean rollback because of the intervening https://github.com/bazelbuild/bazel/commit/b5158a9a677b149e04e844c40a01e9a9dde40783. *** Reason for rollback *** PiperOrigin-RevId: 173957187
* Compute canonical list of options using OptionValueDescription's tracking of ↵Gravatar ccalvarin2017-10-30
| | | | | | | | | | | | | instances. Stop storing the canonical list of arguments separately. For the canonicalize-flags command, we want to avoid showing options that either have no values in their own right (such as expansion options and wrapper options) and instances of options that did not make it to the final value. This is work we already do in OptionValueDescription, so we can generate the canonical form from the values tracked there, instead of tracking it separately. This means the canonical list is more correct where implicit requirements are concerned: implicit requirements are not listed in the canonical form, but now the values they overwrote will be correctly absent as well. Use this improved list for the effective command line published to the BEP. RELNOTES: Published command lines should have improved lists of effective options. PiperOrigin-RevId: 173873154
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 13:24:14 +0000