aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/runtime
Commit message (Collapse)AuthorAge
* 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
* 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
* 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
* 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
* Thread FileSystem through to a single Path#delete call site.Gravatar tomlu2017-10-30
| | | | | | This requires a fairly large amount of changes to fundamental objects like BlazeRuntime, Executor, and so on, as well as changing a lot of test code to thread the file system through. I expect future CLs to be much smaller. PiperOrigin-RevId: 173678144
* Split apart options that should only be set by the client from ↵Gravatar ccalvarin2017-10-27
| | | | | | | | | CommonCommandOptions. client_env and default_override stand apart from the other common options. They can be very long, and should only be used by the environment setup. They should ideally not be passed by option at all, but in the RunRequest proto message, but for now, isolate them so that they don't clutter the common command options, which are passed all over the place. RELNOTES: None. PiperOrigin-RevId: 173592980
* BuildEventStreamer: allow final messagesGravatar aehlig2017-10-26
| | | | | | | | | | After receiving a BuildCompletingEvent, allow some final late messages, but only those not yet seen and announced by that BuildCompletingEvent. This mechanism will be used in a follow-up change to add a message with tool statistics. Change-Id: I979bec5bd946208068faff9a4ddd5245a769f096 PiperOrigin-RevId: 173514552
* Remove feature to allow expansion flags to have values.Gravatar ccalvarin2017-10-18
| | | | | | | | | It was added as a potential fix for --config (an expansion flag with values), but this would have required forcing the parser to know the config's expansions at parsing time, which is not currently possible. Instead, we will use the new addition of option-location tracking to make sure we expand options at a the correct place, even if the expansion is triggered after the fact. This is mostly a straight forward undoing of https://github.com/bazelbuild/bazel/commit/7c7255ec8d6da20526c2c4078c57aadaf3dd3612, except where the context has changed. Notably, implicit requirements are effectively treated like expansion flags, so special casing in OptionDescription could be removed. RELNOTES: None. PiperOrigin-RevId: 172514997
* Track Option placement within a priority category.Gravatar ccalvarin2017-10-18
| | | | | | | | | An option has precedence over previous options at the same enum-valued priority. Track its placement in this ordering explicitly. This will allow after-the-fact expansion of expansion options such that they correctly take precedence or not compared to other mentions of the same flag. This is needed to fix --config's expansion. RELNOTES: None. PiperOrigin-RevId: 172367996
* Accept command lines from tools invoking Bazel.Gravatar ccalvarin2017-10-18
| | | | | | | | | | | For tools that wrap Bazel in some way, the original way that the tool was invoked can be a useful piece of information to track when logging what Bazel did and why. In order to output this information in the same way that Bazel outputs its command lines, we accept --tool_command_line in the structure command line format that Bazel uses in the BEP. These structured command lines are protos that we expect as a base64 encoded byte array. For simple scripts that wish to use this feature without compiling the proto, we will also accept any old string (that cannot be interpreted as a base64 encoding) as a single "chunk" in a structured command line. This is experimental for now and users should not get attached to the format. We will remove the experimental_ prefix when it is stable. RELNOTES: None. PiperOrigin-RevId: 172341216
* BuildEventStreamer: clear a pending BuildStarted event firstGravatar Klaus Aehlig2017-10-16
| | | | | | | | | | | | | | | | | | | | If we receive an event indicating that the build is over, we first post that event and then clear up all pending event by stating that their prerequisite event was aborted (which we can safely assert, as we know we will not process any further events). Now, if a build is aborted (e.g., user interruption) before the build starting event is generated, the streamer can receive a build-finished event while still having an event (e.g., the raw command line) blocked on the build-starting event. So the canonical order of clearing the stream would send a build-finished event before the build-starting event, which can be confusing to consumers of the stream. Therefore, if have to generate an artificial aborted build-starting event, do so first (including clearing the events blocked on the build-starting event) and only afterwards post the build-finished event in the stream. Change-Id: Ib33f16f74b7bee7a963df94bbcad7a56db9f07e3 PiperOrigin-RevId: 172305114
* Report the structured Bazel command line via the BEP.Gravatar ccalvarin2017-10-10
| | | | | | | | | This is part of the effort outlined in https://bazel.build/designs/2017/07/13/improved-command-line-reporting.html. The refactoring of the options parser is not yet complete, so we still do not have complete & correct information about the canonical command line. Where the information is blatantly incorrect, a best approximation was made, with comments and tests documenting the deficiencies. Change the names of the initial CommandLine fields in the BEP to be explicitly identified as unstructured. RELNOTES: None. PiperOrigin-RevId: 171625377
* Move SkylarkSemanticsOptions to the packages/ directory, alongside ↵Gravatar brandjon2017-10-07
| | | | | | | | | SkylarkSemanticsCodec Note that the syntax package and its test package still depend indirectly on the options parser via other Bazel-specific packages. RELNOTES: None PiperOrigin-RevId: 171342823
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 14:16:43 +0000