aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/shell/integration/build_event_stream_test.sh
Commit message (Collapse)AuthorAge
* Set file uploader in BEP integration test to "local".Gravatar tomlu2018-07-13
| | | | | | | This doesn't actually exist, but if the name isn't found in the uploader map then it defaults to "local". RELNOTES: None PiperOrigin-RevId: 204483720
* Remove the legacy loading phase runnerGravatar ulfjack2018-06-08
| | | | PiperOrigin-RevId: 199775400
* Rewrite TargetPattern failure reportingGravatar ulfjack2018-06-07
| | | | | | | | | | | | | | Report failures in TargetPatternFunction, rather than in its callers. Since we can't distinguish between keep_going and nokeep_going modes, we otherwise end up double-reporting errors. In the particular case that's covered by the build_event_stream_test.sh, we end up reporting the same target pattern as both skipped and failed. Unfortunately, this means we cannot report whether the target pattern was skipped or failed, so the pattern_skipped event is now unused (if we agree that this is acceptable, I'll remove the corresponding infrastructure). PiperOrigin-RevId: 199593700
* Refactor root cause reporting in ConfiguredTargetFunctionGravatar ulfjack2018-05-29
| | | | | | We now track Causes instead of plain Labels, which will allow us to do better reporting in the future. Add basic tests. PiperOrigin-RevId: 198380468
* BEP: also report the built artifacts in case of a testGravatar Klaus Aehlig2018-03-26
| | | | | | | | If a test target is built and testing is requested, nevertheless report what was built. Change-Id: Ida25f5f73fd4b5e102f2f4923acc555088495a8a PiperOrigin-RevId: 190431506
* BEP: report analysis failure eventsGravatar Klaus Aehlig2018-01-26
| | | | | | | | | | | | | | ...as completion of the respective top-level targets. In this way, a failure is associated to its root cause, even if the cause is at analysis phase; in particular, visibility errors are correctly associated. For the time beeing, we associate visibility root causes only with labels; it is planned to change that to the more accurate configured labels in a follow-up change. Change-Id: I04121a7cd2099fc65171eae0719fd77b98aef09b PiperOrigin-RevId: 183359798
* 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
* BEP: add a separate id for visibility errorsGravatar Klaus Aehlig2018-01-10
| | | | | | | | | | A build might fail because of a visibility violation that does not happen at a top-level target. To avoid confusion, add a separate namespace for configured targets that are just mentioned to report the details of an error. Change-Id: I86587f7489500f1d888bae6ce3d6f4bd79ea1609 PiperOrigin-RevId: 181448003
* BEP: add commandline for reported actionsGravatar Klaus Aehlig2017-11-10
| | | | | | | | | | The build event protocol reports certain actions that are particularly important to the user, in particular failed ones. Also report the precise command line of those actions, if available. This is useful for IDEs wanting to report errors in a more precise way. Change-Id: I04224185ea46c608ad0dfcdb2e772071ca0736b3 PiperOrigin-RevId: 175203502
* BEP: also report the mnemonic of reported actionsGravatar Klaus Aehlig2017-11-09
| | | | | | | | | Knowing the kind of action that was reported (and hence likely failed) helps users quickly understand what possibly went wrong. So report this information. Change-Id: Ie4869234df895f404ac5d2ff6f05026e4e82ef7e PiperOrigin-RevId: 175043006
* BEP: Add an additional event with tool statisticsGravatar aehlig2017-10-27
| | | | | | | | | | After the completion of the build, also report useful logs/statistics. Do so in a separate event, so that the protocol allows reporting build completion early and purely staticial information later, maybe event after some computations. Change-Id: Ibd221546de76fcffcda7819c300187eac45ebd68 PiperOrigin-RevId: 173548733
* BEP: correctly report unbuilt targets if --nobuild is givenGravatar Klaus Aehlig2017-10-25
| | | | | | | | | If bazel is asked to only analyze a target, but not do any builds, correctly report this as the cause why the obtained configured targets were never completed. Change-Id: I6308f8c222861dc0205a63664d5ea9861dd38b6a PiperOrigin-RevId: 173364084
* BEP: correctly close stream in case of a circular dependencyGravatar Klaus Aehlig2017-10-24
| | | | | | | | | If the build is aborted due to a cyclic dependency, correctly report so in the build event protocol. In particular, close the stream of events. Change-Id: Iff86213904a99c6af6a1da90fb229bba8e51c91f PiperOrigin-RevId: 173247825
* BEP: correctly report the cause of unbuilt targets if --noanalyze is givenGravatar Klaus Aehlig2017-10-20
| | | | | | | | | If bazel is asked to only load target, but not perform an analysis phase, correctly report this as the cause why the obtained targets wer never configured. Change-Id: Ib630a6dc1b955b810a6cc40254c0ae746e2eca1e PiperOrigin-RevId: 172787777
* 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
* BEP: explicitly report failures associated with a label as suchGravatar Klaus Aehlig2017-10-16
| | | | | | | | | | There is a conceptual difference between the (maybe unsuccessful) completion of a top-level target and a label as the root cause for a failure (i.e., a missing source file). Indicate that difference as such, by having a separate message for failures associated with an unconfigured label. Change-Id: I3f2e20d4dc85782eb11b104a7baf089e66d972e7 PiperOrigin-RevId: 172299938
* Some tests depend on the target pattern evaluation strategy used.Gravatar aehlig2017-10-16
| | | | | | | Make them specify the target pattern evaluator they need. RELNOTES: None PiperOrigin-RevId: 172296001
* Some tests depend on the target pattern evaluation strategy used.Gravatar aehlig2017-10-16
| | | | | | | Make them specify the target pattern evaluator they need. RELNOTES: None PiperOrigin-RevId: 172100319
* 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
* build_event_stream_test: fix usage of ed(1)Gravatar Klaus Aehlig2017-09-29
| | | | | | | | | | | | | | Unfortunately the various ed(1)s are different in subtle ways. The difference that hit us here is the different treatment of the implicit 'e' command when ed is started with a file as argument; GNU ed writes the answer of that command (i.e., the number of bytes read) on stderr, whereas ed on FreeBSD writes it on stdout. So, let's merge the two output channels and throw away the first answer explicitly. Fixes #3842. Change-Id: I4ef394957cdc316f896b54ca218d4f118465caff PiperOrigin-RevId: 170506490
* BEP: correctly report AliasConfiguredTargetsGravatar Klaus Aehlig2017-09-29
| | | | | | | | | When reporting the completion of a target specified by an alias, report the label of the alias, not that of the target being aliased to. Change-Id: If8416ceef73b01b7531ffa0012251f25a4e9f062 PiperOrigin-RevId: 170466076
* Make build_event_stream_test more portableGravatar aehlig2017-09-27
| | | | | | | | | - Make regexp to look for more strict; 'success' is too generic a keyword as it also matches the UI output 'Build did NOT complete successfully'. - Do not rely on backticks throwing away trailing carriage returns; mask them instead. PiperOrigin-RevId: 170063590
* build_event_stream_test: simplify quotingGravatar Klaus Aehlig2017-09-18
| | | | | | | | | ...by quoting the delimiter of the here-documents, instead of the documents themselves. This is possible as the here-documents are constants in that test (not depending on the test setup). Change-Id: If272060ce9f6384821e4bd0bd9033925bd1efe9c PiperOrigin-RevId: 169080394
* BEP: Upon missing test targets, still generate a finished eventGravatar Klaus Aehlig2017-09-15
| | | | | | | | If a test command is aborted as no tests are found, still generate a BuildComplete event in the sequence of build events to properly report the exit status. Change-Id: Id811a116b309a26e67332947b3a5c66363b1ce9c PiperOrigin-RevId: 168703240
* BEP: always close stream, even if aborted due to missing testsGravatar Klaus Aehlig2017-09-12
| | | | | | | | | | If testing is requested, but no tests are found, the build is aborted. Ensure that even in this case the steam of build events is internally closed (i.e., all announced events are reported, the last event is marked as such). Change-Id: I88763ed6ccd7793deedbcb3428df7e8d289efa23 PiperOrigin-RevId: 168364127
* BEP: Add TargetConfigured events also for aspectsGravatar Klaus Aehlig2017-09-01
| | | | | | | | | Adding an event about which completed aspects to expect allows for earlier feedback of what the aspect is doing. It also allows consumers of the build event stream to prepare for the TargetCompleted events of the aspect. Change-Id: I29ef15472867a7169222e0394c7fe061fd1d2994 PiperOrigin-RevId: 167248206
* BEP: add tool_tag explicitlyGravatar Klaus Aehlig2017-08-30
| | | | | | | | | Add the tool tag explicitly in the OptionsParsed event. In this way, consumers of the stream can more easily associate an invocation with a tool. Change-Id: I6040e91f657082782bf8010a6576001118672e2d PiperOrigin-RevId: 166862895
* Replace deprecated `set` constructor and its order names in integration testsGravatar vladmos2017-08-24
| | | | | | | The name `set` and order names "stable", "compile", "naive_link", and "link" are deprecated and will soon be removed from Blaze. PiperOrigin-RevId: 166341984
* BEP: Make tags available in TargetConfigured eventGravatar Klaus Aehlig2017-08-14
| | | | | | | | | | | | The tags associated with a rule is information that is useful as information about the target, independent of the configuration. At the moment, tags cannot be configuration-dependent anyway, but even if the extend bazel it that way, the union of all possible tags is still useful information. Change-Id: Iabca0c28b0da4b13b8a62b2638a881c53cc70ccc PiperOrigin-RevId: 164996472
* BEP: move configuration-independent information to TargetConfigured eventGravatar Klaus Aehlig2017-08-11
| | | | | | | | | | Some information about a target is configuration independent and therefore can already be provided at a target level (i.e., in the TargetConfigured event). Do so, to have that information available earlier and, once the deprecation period is over, avoid redundant information in the stream. Change-Id: I8021ce3dd2a8168d409ea513190c4e3a349dbc2f PiperOrigin-RevId: 164967059
* BEP: do not generate test summaries for broken testsGravatar Klaus Aehlig2017-08-02
| | | | | | | | | If a test fails to build, we obviously cannot run it. Therefore, it does not make sense to have a summary of the individual test runs. Change-Id: I0445e7a58fc5c1f4feaa592a13da1c7f9c9be083 PiperOrigin-RevId: 163866309
* Add configuration and target label to ActionCompletedId.Gravatar Eduardo Colaco2017-07-27
| | | | | | | | This is a first step on moving the configuration checksum and target label from the ActionExecuted payload and into ActionCompletedId. Change-Id: I989c9b708cd2a4172f6483d97bc7842d9841e3a8 PiperOrigin-RevId: 163233097
* BEP: Merge all failures into the Aborted eventGravatar Klaus Aehlig2017-07-24
| | | | | | | | | In this way, for each event there can only be two event payloads for every event identifier: the expected one, and the Aborted event. The type of failure will be reported in the AbortReason enum value. Change-Id: Icce225ec156d1fc20c8facd18df13343712f775c PiperOrigin-RevId: 162911732
* Use new actions API in docs.Gravatar Dmitry Lomov2017-07-21
| | | | | Change-Id: Ibbc41193ca3f577fbbd1674e9dd1c7f04a246e93 PiperOrigin-RevId: 162612615
* BEP: Report configuration for all actionsGravatar Klaus Aehlig2017-07-14
| | | | | | | | | | Whenever we report an action in the build event protocol that has a configuration associated with it, report the configuration as well in the protocol (and not only the checksum, if the configuration is not that of one of the top-level configured targets). Change-Id: I9b085d5381b3c3509b4f3b99c8a77bc8fba6abfe PiperOrigin-RevId: 161789745
* build_event_stream_test: stop daemon before removing filesGravatar Klaus Aehlig2017-07-10
| | | | | | | | | | | | | | | | Bazel gets confused when files get removed where the daemon still has a handle on. By the way java closes a file (guarantees that the content is there, but the OS-level close can happen later), bazel can still have a handle on a build-event file when the test is cleaned up (but only on OSes where we cannot reliably reap the grand-children). Mitigate this by explicitly shutting down bazel before any cleaning up of the build event file. Fixes #3349. While there, also drop manual clean up that is done by the test framework anyway. Change-Id: Iec0e3d5c3f02dae496b361ef97abe5ef982ceb47 PiperOrigin-RevId: 161383286
* Restrict writing build events to a white-listed set of commandsGravatar Klaus Aehlig2017-07-07
| | | | | | | | | It is not desirable to have a build-event stream for all invocations of blaze; so restrict the BuildEventServiceModule to be only active if the executed command is in a white list of commands for which having build events is desirable. Change-Id: Id4acf9468f67b1af7fc8ea703785df5229c69258 PiperOrigin-RevId: 161207563
* Make build_event_stream_test more robustGravatar aehlig2017-07-07
| | | | | | | | | | | | | ...by makeing it independent of the test executor; in particular, do not rely on the wrapper to create the test.xml files if the test fails to do so, and do not assume a particular name (e.g., remote execution might decide to call the files "remote_1.xml"). Also, make the constructor of VisibilityErrorEvent public, to allow extensions of bazel to generate visibility errors as well. RELNOTES: None PiperOrigin-RevId: 161087809
* Fix JSON expectationsGravatar Klaus Aehlig2017-07-05
| | | | | | | | With commit 97a1db383cc unnecessary whitespace in the JSON output was removed (which is a feature). Adapt the test expectation accordingly. Change-Id: I76026f45a80bc9d791833e0c37f546804052591f PiperOrigin-RevId: 160970633
* AspectCompleteEvent: correctly report artifacts for a failed aspectGravatar Klaus Aehlig2017-07-05
| | | | | | | | | | If an aspect completed unsuccessfully, there are no artifacts created. Internally, this is represented by the ArtifactsToBuild object being a null pointer. When asked for the built artifacts correctly handle that case and return an empty Collection. Change-Id: Ie0b0486354bb217834254518f35c97b7c9529481 PiperOrigin-RevId: 160827964
* Introduce ctx.actions.write in place of ctx.file_action.Gravatar dslomov2017-06-30
| | | | | RELNOTES: None. PiperOrigin-RevId: 160630261
* build_event_stream_test: action listener is still experimentalGravatar Klaus Aehlig2017-06-29
| | | | | | | | | | Commit 1e0628d18c2e3defaddd935ffb41edbf3ef40339 marked the build_event_*_file options as no longer experimental and adapted the corresponding tests to use the new option name; while doing so, accidentally too many uses of the word experimental were removed. Fix this. Change-Id: I817ea2bc848085f8ba4930b87b54942935e69325 PiperOrigin-RevId: 160417058
* Writing build events to a file is no longer experimentalGravatar aehlig2017-06-28
| | | | | | | | Reflect this by renaming the options appropriately. While there, also add categories to those options. RELNOTES: writing build events to a file is no longer experimental PiperOrigin-RevId: 160400332
* BEP: Gracefully handle null configurationsGravatar Klaus Aehlig2017-06-28
| | | | | | | Those may occur, e.g., if the target is simply a source file. Change-Id: Ia64c54e8543dd93712b00428c443922c67e2b6cd PiperOrigin-RevId: 160278149
* BEP: also report test sizesGravatar Klaus Aehlig2017-06-28
| | | | | | | The size of a test is a relevant property of a test target. Report it. Change-Id: Ia529a11f4a6920bca7d233e3493640d319cca5ae PiperOrigin-RevId: 160268370
* Add 'ctx.actions' and implement 'ctx.action.declare_file'.Gravatar dslomov2017-06-27
| | | | | RELNOTES: None. PiperOrigin-RevId: 160264501
* BEP: Support longer streams on non building commandsGravatar Klaus Aehlig2017-06-26
| | | | | | | | | | | | | While the build event protocol is mainly targeted for commands that actually build, a minimal stream is generated for all commands. For commands like "query", it is desirable that the stream contains the full output of the command. To achieve this, introduce an optional second event indicating the end of the stream; note that the NoBuildEvent has to come before the payload answer as the experimental UI uses this event to determine the transition to the payload answer that is passed through unchanged. RELNOTES: None. PiperOrigin-RevId: 159977543
* Make NoBuildEvent an instance of BuildEventGravatar Klaus Aehlig2017-06-19
| | | | | | | | | | | Not all bazel invocations produce a BuildStartingEvent; in fact, not all commands include building. Those invocations produce a NoBuildEvent instead. However, some of those invocations, like "query", might still have important machine-readable information to report, like errors in BUILD files. So, make the NoBuildEvent a build event, capable of starting a stream of build events. Change-Id: I7cab65f029cdc0176ea5c4970308de296fb73177 PiperOrigin-RevId: 159230205
* Propagate postable events further upGravatar Klaus Aehlig2017-06-14
| | | | | | | | | | | | With the introduction of the ExtendedEventHandler, SkyFunctions were given the possibility to post additional Postable events in addition to the standard events. As SkyFunctions have to be restartable, events are collected first and only posted after the function is finished. Make sure that this also applies to postable events and they are not dropped. Change-Id: Ie1c3a0134935c75ea984fa2cc924e7327a9da81f PiperOrigin-RevId: 158964337
* BEP: report visibility errorsGravatar Klaus Aehlig2017-06-01
| | | | | | | | On finding a visibility error, report it directly for that target, instead of relying on the implict "abort" message for targets that have not been built. Change-Id: I5e45722a1117afca3bc8eeebd05179425b995172 PiperOrigin-RevId: 157592518
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 05:13:02 +0000