aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/actions/ActionExecutionMetadata.java
Commit message (Collapse)AuthorAge
* Allow CommandLine expansion to throw an exception.Gravatar tomlu2017-08-24
| | | | | | | | | | | | | | | | | | | This paves the way for Skylark-side compact command lines that can fail during expansion. In general, expansion happens in these scenarios: * Action execution expands the command line to execute it. This is fine since we are well equipped already to handle failing actions. * In the analysis phase we expand command lines to investigate whether we need a params file. This could be moved to the execution phase, which would have the benefit of getting params files out of the action graph and saving memory. * Key computation expands the command line. This could be fixed by allowing command lines to compute their own keys (which wouldn't try to expand the command line). This could have the benefit of being more efficient. * Extra actions expand the command line to construct the extra action proto. This could maybe be deferred to the execution phase (writing the extra action), which would also be more memory efficient. For failed key computations, we return a singleton "error" key. This means multiple actions that will fail will map to the same key. These actions will necessarily fail if executed, so we should not need to worry about these ending up in the action cache. If we do manage to make the command line compute its own keys then this will become moot in the future. RELNOTES: None PiperOrigin-RevId: 166266385
* Clean up the semantics of input discovering actions a bit by making ↵Gravatar Lukacs Berki2017-02-28
| | | | | | | | | | | | updateInputs() and inputsKnown() non-overridable and removing setInputs(). This comes at the cost of adding a flag to every action instance that's not used for non-input-discovering actions, but I think that's a deal. Simpler APIs are good, mmmmkay? Also fixed a few pre-existing issues in TestAction and ObjcCompileAction. -- PiperOrigin-RevId: 148749734 MOS_MIGRATED_REVID=148749734
* Extend Action interface by client variablesGravatar Klaus Aehlig2016-08-24
| | | | | | | | | | | | | | | | As per our design on [Specifying environment variables](http://bazel.io/designs/2016/06/21/environment.html), actions may depend, in a controlled way, on the environment in which the Bazel client is invoked. Those environment variables are considered essential for the action, in the sense that it was to be repeated if either of them changes their value (note that other variables in client environment may well change without invalidating actions). Therefore, make the variables that need to be taken from the client environment part of the meta data for actions. -- Change-Id: I2ff6cf40b4ce8e0fea5c7e464f5f3b3e693025ac Reviewed-on: https://bazel-review.googlesource.com/#/c/5390 MOS_MIGRATED_REVID=131150211
* Move methods getRunfilesSuppliers, inputsKnown and discoversInputs fromGravatar Rumou Duan2016-05-11
| | | | | | | | | | ActionAnalysisMetadata to ActionExecutionMetadata. They are not called in analysis phase. RELNOTES:None. -- MOS_MIGRATED_REVID=121976260
* Split ActionMetadata into ActionAnalysisMetadata and ActionExecutionMetadata.Gravatar Rumou Duan2016-04-26
Except in action execution logic (ActionExecutionFunction, SkyframeActionExecutor, etc.), switch Action interface references to either ActionAnalysisMetadata if possible or ActionExecutionMetadata. -- MOS_MIGRATED_REVID=120723431