aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/runtime
Commit message (Collapse)AuthorAge
* Remove final inplace references in the tests.Gravatar ccalvarin2018-06-29
| | | | | | | I missed these in https://github.com/bazelbuild/bazel/commit/654c77c603c039142d8b257f47bdaf14ac507c47. RELNOTES: None. PiperOrigin-RevId: 202706112
* Remove --allow_undefined_configsGravatar ccalvarin2018-06-28
| | | | | RELNOTES: --[no]allow_undefined_configs no longer exists, passing undefined configs is an error. PiperOrigin-RevId: 202518987
* Automated refactor of Label.parseAbsolute() to always pass a repository mappingGravatar dannark2018-06-27
| | | | | RELNOTES: None PiperOrigin-RevId: 202360925
* Remove fixed point config expansion.Gravatar ccalvarin2018-06-14
| | | | | | | Deprecates the flag, though it continues to exist as a no-op so that users get a warning before errors. RELNOTES: --noexpand_configs_in_place is deprecated. PiperOrigin-RevId: 200572053
* Remove special casing from processes stat line.Gravatar Googler2018-05-25
| | | | | | | | Fixes #5263 RELNOTES: execution strategies line no longer handles differently the case where all processes have the same strategy. PiperOrigin-RevId: 198057496
* Add BuildEventProtocolOptions; use to enable/disable important_outputsGravatar ulfjack2018-05-18
| | | | | | | The important_outputs field is deprecated, and this adds a flag to disable its generation entirely. PiperOrigin-RevId: 197186530
* Move coverageSupport and coverageReportGenerator from BuildConfiguration toGravatar dbabkin2018-05-18
| | | | | | | TestConfiguration. RELNOTES:none PiperOrigin-RevId: 197135911
* Rename BuildEventConverters to BuildEventContextGravatar ulfjack2018-05-17
| | | | | | | This is in preparation for adding options to the class, which can be used to modify the behavior of build events posted to the BEP. PiperOrigin-RevId: 196997573
* Remove AbruptException(ExitCode exitCode) constructor.Gravatar lpino2018-05-17
| | | | | | | | | This constructor was creating an Exception with a null message leading to possible NullPointerExceptions in a few places in our codebase. The call sites have been replaced with calls to AbruptException(String message, ExitCode exitCode) with a meaningful message. PiperOrigin-RevId: 196973540
* Port bazelrc flags into their own module.Gravatar ccalvarin2018-05-16
| | | | | | | | | This way the documentation logs them correctly as named "bazel," and describes the correct behavior. Needed for #4502. RELNOTES: None. PiperOrigin-RevId: 196837021
* Add --ignore_all_rc_files startup options.Gravatar ccalvarin2018-05-15
| | | | | | | | | | | | | This overrides --bazelrc and --[no]master_bazelrc regardless of order. Like --bazelrc and --[no]master_bazelrc, it cannot be mentioned in an rc file, this would be a contradiction. This flag is useful for testing, and for having a version-agnostic way to turn off all rc files, such as in the canonical command line reporting. Now that blazerc and bazelrc are separate, this is necessary. If explicit values for --bazelrc or --master_bazelrc are provided which are now ignored, Bazel will warn the user. #4502 Alternatives considered - We could avoid this flag but would need to have some well-documented, reusable list of the startup flags that effectively come to the same effect. This would be necessary in our integration tests and in the CommandLineEvent and other places where rc files need to be completely disabled for correctness. We decided that this startup option was more straightforward and usable for both users and Bazel devs: it shouldn't be used when more fine-grained control is needed, but provides warnings if users are likely to be confused by the outcome. RELNOTES: None. PiperOrigin-RevId: 196750704
* Use the local JDK as the default target javabaseGravatar cushon2018-05-14
| | | | | | and continue to use the embedded JDK as the default host_javabase. PiperOrigin-RevId: 196471714
* Remove BuildConfiguration.Fragment#setupActionEnvironment().Gravatar lberki2018-04-11
| | | | | | | This is accomplished by moving it to ConfiguredRuleClassProvider. This also suggests a neat way to get rid of logic in ShellConfiguration.Loader() by moving the determination of the shell executable, there, too, but not in this change. RELNOTES: None. PiperOrigin-RevId: 192411609
* Remove alphabetical sorting of options in the canonical list.Gravatar ccalvarin2018-04-09
| | | | | | | This was broken for --config. Doing this properly requires keeping the order in which the options were given, which could be done either by filtering the ordered list according to which values affect the final outcome or by tracking the order correctly. I picked the later: the option order was not explicitly tracked for expansions before but now it is. RELNOTES: canonicalize-flags no longer reorders the flags PiperOrigin-RevId: 192132260
* Remove BuildConfiguration.Fragment#getReservedActionMnemonics() in favor of ↵Gravatar lberki2018-04-09
| | | | | | | | | encoding the same in ConfiguredRuleClassProvider. This is a step towards dumbing down BuildConfiguration.Fragment and the ConfigurationFactoryLoader, which is in needed so that we can rewrite C++/Java/Python rules in Skylark without having to introduce the concept of "configuration loader" in Skylark, too. RELNOTES: None. PiperOrigin-RevId: 192104912
* Disallow undefined configs by default.Gravatar ccalvarin2018-04-06
| | | | | | | | This brings it in line with other flags, where a malformed value is an error. RELNOTES(INC): --config=foo will error if no 'foo' config exists. PiperOrigin-RevId: 191910781
* Add stats about cache hits and execution strategies to Bazel's UI.Gravatar Googler2018-04-03
| | | | | | | 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
* Remove category checking from incompatible changes.Gravatar ccalvarin2018-03-30
| | | | | | | String categories are deprecated, replace this special-cased value with a specific OptionMetadata tag, TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES. RELNOTES: None. PiperOrigin-RevId: 191069412
* Remove categories from Bazel options.Gravatar ccalvarin2018-03-28
| | | | | | | | | 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
* Remove last few test uses of ConfiguredTarget#getConfiguration. Only uses ↵Gravatar janakr2018-03-27
| | | | | | are now internal, and the one that https://github.com/bazelbuild/bazel/commit/d350a897f6182d637ea819c41cd292a50c2db53d just snuck in... PiperOrigin-RevId: 190705224
* Thread configuration map through TestFilteringCompleteEvent. This isn't the ↵Gravatar janakr2018-03-27
| | | | | | most elegant solution, but I don't have a better idea. PiperOrigin-RevId: 190656869
* Refactor and cleanup the sandboxing code.Gravatar Philipp Wollermann2018-03-23
| | | | | | | | | | | | | - 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
* Add a DefaultBuildOptions specifying default build flags that may differ ↵Gravatar mjhalupka2018-03-22
| | | | | | 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
* ActionOwner references only BuildEvent instead of full BuildConfigurationGravatar shahan2018-03-10
| | | | | | This reduces the size of its serialized representation. PiperOrigin-RevId: 188597127
* Improve the warning for malformed recursive configs.Gravatar ccalvarin2018-03-09
| | | | | | | | | 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
* BEP: Add a --build_event_publish_all_actions flag to allow all actions to be ↵Gravatar ruperts2018-03-02
| | | | | | | 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
* Expose --output_user_base to the Bazel server processGravatar Klaus Aehlig2018-02-27
| | | | | | | | | | | ...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
* expectThrows has been renamed to assertThrowsGravatar cushon2018-02-24
| | | | | | More information: https://github.com/junit-team/junit5/issues/531 PiperOrigin-RevId: 186900384
* 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
* 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
* Rename Root to ArtifactRoot.Gravatar tomlu2018-01-16
| | | | | | This is slightly more descriptive, and we will potentially want to use the name Root for a broader concept shared between ArtifactRoot and RootedPath. PiperOrigin-RevId: 182082367
* 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
* Fix Action subclasses so that the execution platform is properly set inGravatar John Cater2018-01-04
| | | | | | | | | more cases. Part of #4128. Change-Id: Ife5e4581f91ac07931d193ed5eaa256aab3ad047 PiperOrigin-RevId: 180826445
* Move config transition definitions out of lib.packages.Attribute.Gravatar gregce2017-12-21
| | | | | | | | | | | | | This cleans up a legacy API from Bazel's "static configuration" days, when transition definitions involved deep and complex logic in the analysis code. That was too much cruft to embed into lib.packages. But the modern definitions are way simpler and thus easier to embed. This change only *copies* the existing definitions. Because a lot of references will have to be updated, we'll migrate the move over a few changes. PiperOrigin-RevId: 179859293
* 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
* Move compulsory ProcessWrapperUtil parameters into its builder() method, to ↵Gravatar ruperts2017-12-20
| | | | | | | be consistent with LinuxSandboxUtil. RELNOTES: None. PiperOrigin-RevId: 179758847
* 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
* Add a sanity check to prevent creation of Artifacts with an empty pathGravatar ulfjack2017-12-19
| | | | | | And fix the tests that were doing this. PiperOrigin-RevId: 179548691
* 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
* Make ProcessWrapperUtil aware of the execution statistics file, and add new ↵Gravatar ruperts2017-12-05
| | | | | | | ExecutionStatisticsProvider. RELNOTES: None. PiperOrigin-RevId: 178056182
* 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
* 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