aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/shell/integration/experimental_ui_test.sh
Commit message (Collapse)AuthorAge
* Only report progress after a build has started.Gravatar Benjamin Peterson2017-07-31
| | | | | | | | | | | | Rather than assuming that all events are part of a build until NoBuildEvent or BuildCompleteEvent are posted, only start reporting build progress after a BuildStartingEvent or a NoBuildEvent with showProgress() true happens. This fixes https://github.com/bazelbuild/bazel/issues/3449. Change-Id: I78372a2286a4595cf3301c998be2c9036ad0f4b7 PiperOrigin-RevId: 163447622
* experimental_ui_test: fix test_strategy optionGravatar Klaus Aehlig2017-06-09
| | | | | Change-Id: Ieed7e16860e483b69081a69420681b6c1bf6628c PiperOrigin-RevId: 158534203
* experimental_ui_test: run tests locallyGravatar aehlig2017-06-09
| | | | | | | | | This integration test is about the UI, so any tests the bazel under test executes are toy examples. So there is no reason not to run them locally. RELNOTES: None PiperOrigin-RevId: 158509077
* experimental_ui, rate limiting test: work around output by the clientGravatar aehlig2017-06-08
| | | | | | | | | | | | When the experimental UI is told to rate limit the amount of output generated, this limit does not include startup messages generated by the client. Make the test aware of that behaviour by allowing a bit more output than the UI limit, to take into account the client startup messages. To keep the test still strict increase the output generated by the actions a lot, so that the client output is small compared to what we expect and limit. PiperOrigin-RevId: 158386698
* experimental UI: Support limiting consoleGravatar Klaus Aehlig2017-05-23
| | | | | | | | | | | | Add an option allowing to set a hard limit on the number of characters bazel will write to stdout/stderr (combined). In this way, it can be avoided to overwhelm the user with information (especially, if the invocation of bazel is wrapped in some way). Once the limit is approaching, bazel will try hard to meaningfully reduce the output, but will ultimately resort to just dropping output completely. Change-Id: I49cce96cc6a025c9753632dd489021766df81077 PiperOrigin-RevId: 156849105
* Reduce the time for the slow testGravatar Klaus Aehlig2017-04-27
| | | | | | | | | | ...now that the test_times_fresh test case is removed which assummed that this test would run at least for 10 seconds. While there, also increase the number of shards to ensure that at most two test cases are run in each shard. Change-Id: Ia694afdaefa1bf78c4cf1755d9d98507fffeb7d2 PiperOrigin-RevId: 154411952
* Experimental UI: only show progress in terminal title if curses enabledGravatar Klaus Aehlig2017-04-07
| | | | | | | | | If told to not use curses, also do no show the progress in the terminal title, even if told to do so. If curses are not available, most likely OSC controll sequences are not available either. Change-Id: I0e14e36aaa32dfeffb52ed701e31b83085d63e68 PiperOrigin-RevId: 152393651
* Create a proper wrapper script for executing "bazel" in the integration tests.Gravatar Luis Fernando Pino Duque2016-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently a call to "bazel" in an integration test means calling a (quite hidden) function in test-setup.sh which actually calls "$bazel" defined in "shell/bazel/testenv.sh" which is equal to "$(rlocation io_bazel/src/bazel)". This is extremely confusing and error prone. The new mechanism is to add a wrapper script to shell/bin called bazel and export this directory to the PATH. Moreover, not every test loads the same test environment, for instance consider how bazel_query_test loads the test environment: - Load shell/integration/testenv.sh which loads, - shell/bazel/test-setup.sh which loads, - shell/bazel/testenv.sh which loads, - shell/unittest.bash which loads, - shell/testenv.sh Again this is error prone and specially hard to understand, in fact each test writer needs to decide which of these testenv to load. This change fixes all of this by having only one testenv.sh and summarizing the test setup in integration_test_setup.sh. Namely, for any new integration test, the developer needs to load integration_test_setup to get the environment set up including the unittest framework (also it helps to attract contributions). This change also allows to open sourcing client_sigint_test: Since bazel was a function client_sigint_test was using a wrong process id to interrupt the build. The problem is that $! returns bash's id instead of the id of the process running in the background when using a function instead of an executable. A few tests needed to be adapted to the new infrastructure. -- MOS_MIGRATED_REVID=136470360
* experimental UI: honor --show_timestampsGravatar Klaus Aehlig2016-06-29
| | | | | | | | | | | In the experimental UI, also support the --show_timestamps option which asks that for each event a timestamp be added to the the output. Fixes #1436. -- Change-Id: I8f9db958525edfbca12ed2c1f1396f25f865b897 Reviewed-on: https://bazel-review.googlesource.com/#/c/3916 MOS_MIGRATED_REVID=126165328
* experimental UI: honor --progress_in_terminal_titleGravatar Klaus Aehlig2016-06-27
| | | | | | | | | | Make the experimental UI honor the --progress_in_terminal_title options which requests that the terminal title be set to a description of the current progress. -- Change-Id: I8ebded9ebb7e9f821344165fca6b5f6b9b254c68 Reviewed-on: https://bazel-review.googlesource.com/#/c/3904 MOS_MIGRATED_REVID=125953773
* experimental UI: Avoid empty linesGravatar Klaus Aehlig2016-06-27
| | | | | | | | | | ...to save a bit of horizontal space in the scroll-back buffer. The color-coding already gives enough navigation hints. -- Change-Id: Id0e5decc6bd495a99ec839c096700406d8d1bab9 Reviewed-on: https://bazel-review.googlesource.com/#/c/3902 MOS_MIGRATED_REVID=125943242
* experimental UI: be less verbose about test summariesGravatar Klaus Aehlig2016-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | To keep the noise of messages in the scroll-back buffer low, limit which test summaries are shown there. - If a test fails to build, the error message about the build failure is already in the scroll-back buffer---and more useful to the user anyway. - If a test is not run (either because the user interrupted the build, or because of a build error), then either the user is aware of it anyway or the information about the build failure is present and more useful. Also, this is only detected at the end of the build, were a summary of the tests is shown; hence avoid duplication here. - If a test has status failed and there is precisely one failure log, then the summary does not provide any useful information compared to the individual FAIL message in the scrollback buffer. While there, also show the precise status of the summary. -- Change-Id: I13665db24f956c8d8b651dc38859649085b8bbcf Reviewed-on: https://bazel-review.googlesource.com/#/c/3830 MOS_MIGRATED_REVID=125339810
* Make experimental UI honor --noshow_progressGravatar Klaus Aehlig2016-06-15
| | | | | | | | | | | | While there is little value in using the experimental UI if no progress output is desired, we still want the experimental UI to serve as a drop-in replacement for the old one, including the ability to not show any progress. -- Change-Id: I54c67a6f432541611da8b4ab7e7f88bb85926391 Reviewed-on: https://bazel-review.googlesource.com/#/c/3803 MOS_MIGRATED_REVID=124833575
* experimental UI: track touched packages during loading/analysisGravatar Klaus Aehlig2016-05-30
| | | | | | | | | | | | | | To give a better understanding of which packages are on the critical path during loading and analysis, provide information in the same way as during execution: show the earliest started, but not yet completed package. As not all packages looked at during the analysis phase are reported to the progress receiver, use a custom class to aggregate those data. -- Change-Id: I03c25efdecb4124e1bc06fce8be9175dc56b5500 Reviewed-on: https://bazel-review.googlesource.com/#/c/3700 MOS_MIGRATED_REVID=123408689
* Improve pass-through during buildGravatar Klaus Aehlig2016-05-13
| | | | | | | | | | | | | If tests are run with --test_output=streamed, output has to be passed through before the end of the (overall) build. In this situation, enforcing a line-end to redraw the status bar messes up the output that is streamed through. Therefore, buffer stdout/stderr to full lines and pass them through without extra newlines added. -- Change-Id: I52d5dfbd1cb30a6ce2d7d2fd34658a606abcc277 Reviewed-on: https://bazel-review.googlesource.com/#/c/3620 MOS_MIGRATED_REVID=122248012
* experimental_ui: when analyzing analyzing one target, show itGravatar Klaus Aehlig2016-05-09
| | | | | | | | | | | | In the progress bar of the experimental state tracker, when reporting that precisely one target is being analyzed, show that target. While there, also consistently switch to American spelling. -- Change-Id: Ib9027145aed69e757a7caf7076abdeb1c5ebeb30 Reviewed-on: https://bazel-review.googlesource.com/#/c/3583 MOS_MIGRATED_REVID=121833343
* Signal that the version command does not buildGravatar Klaus Aehlig2016-04-19
| | | | | | | | | | | | The version command is not expected to every run any actions. Hence any messages about progress of the build process or running actions would be confusing. Therefore, signal this fact to allow the experimental UI to present information accordingly. -- Change-Id: I8a75704a39e161f52c4d008677f62e4b36097647 Reviewed-on: https://bazel-review.googlesource.com/#/c/3387 MOS_MIGRATED_REVID=120203058
* Remove experimental_ui integration tests that depend on timingGravatar Klaus Aehlig2016-04-14
| | | | | | | | | | | | While the timing assumptions in those tests were quite generous (a sleep 10 should not take 15s, an event supposed to happen every second should be observed at least once in a 3 second interval), it seems that under really heavily loaded test environments those assumptions do not hold true. So remove the tests, as it is better to not have integration tests for timing properties than to have flaky ones. -- MOS_MIGRATED_REVID=119826405
* experimental UI: show passed and failed testsGravatar Klaus Aehlig2016-04-14
| | | | | | | | | | | | In the experimental UI, show the most recent finished test in the (long) progress bar. For failed test, immediately write an entry to the scroll-back buffer. In this way, the user can get an already investigate test failures while other tests are still running. -- Change-Id: I5df29dc55b979c8547e99e9ac3f60563736b48e8 Reviewed-on: https://bazel-review.googlesource.com/#/c/3351 MOS_MIGRATED_REVID=119732631
* Experimental UI test: deflake test_times_fresh().Gravatar Laszlo Csomor2016-04-12
| | | | | -- MOS_MIGRATED_REVID=119609967
* exprimental_ui_test: set --show_progress_rate_limitGravatar Klaus Aehlig2016-04-12
| | | | | | | | | | The test on the freshness of the timing results depends on the show_progress_rate_limit; to avoid depending on defaults or rc-files, set it explicitly on the command line. While there, also move options before target name. -- MOS_MIGRATED_REVID=119535250
* Keep output of experimental UI short if curses cannot be usedGravatar Klaus Aehlig2016-04-12
| | | | | | | | | | | | | | | | | | | | As the experimental UI should be usable in all situations, we also have to care about the situation where updating the status bar in place is not possible. In this case, we have to make sure we do not litter the output to much. To achieve this, - we use the short one-line version of the status bar, and - reduce the frequency for time-based updates. Unfortunately, this means that we have to further complicate the timing mechanisms for updating the progress bar. We now have 3 time intervals in place: - a short one, after which we update the progress bar, if we dropped an update due to too frequent events, - an intermediate one, describing the frequency of status bar updates due to time passing, and - a long one for purely time-based updates of the progress bar if we cannot update it in place. -- Change-Id: I5d59ba174c4d290b07181620e238362a8d21a6eb Reviewed-on: https://bazel-review.googlesource.com/#/c/3295 MOS_MIGRATED_REVID=119527089
* experimental_ui_test: avoid flakyness by disallow test cachingGravatar Klaus Aehlig2016-04-12
| | | | | | | | | | Under certain conditions it might happen that simultaenously running instances of the experimental_ui_test share cached results, leading to the (deliberatly) slow test taking shorter than tested for. Fix this by adding the --nochache_test_results options to the test run in the test. -- MOS_MIGRATED_REVID=119525789
* Rate limit updates in the experimental UI and keep it freshGravatar Klaus Aehlig2016-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the experimental UI honor the --show_progress_rate_limit flag. While just dropping a status bar update if it happens too soon after the last update shown would be easy, there are a few delecate points to keep in mind. Assume that several updates happen after another and then nothing for a long time. Then the last(!) update is the one the user wants to see, as it most accurately reflects which actions are running during the long period. However, the simple dropping algorithms would show the first of those state updates. So, whenever we refrain from updating due to the rate limit we to make sure that an update will happen soon-ish, even if no events are reported for a long time. We do this by having (at most) one thread that periodically triggers updates of the progress, if the rate limit allows this. This mechanism is additionally used to ensure that the progress bar, when showing time-dependent data is kept fresh. For this property we also add a test. There is a third point to keep in mind: users (and also our tests) want to see all phases. However, some phases (like loading) might be so short that they happen in its entirety within a refresh interval. Therefore, whenever a new important phase starts, we skip the rate limit interval once; note that this happens at most a fixed number of times during the entire build. -- Change-Id: Iee68194d7eb92d6ef9efdc7abde6f56edfa21ce8 Reviewed-on: https://bazel-review.googlesource.com/#/c/3293 MOS_MIGRATED_REVID=119515272
* experimental UI: only wrap lines if curses are usedGravatar Klaus Aehlig2016-04-11
| | | | | | | | | | | | | Lines are wrapped in the progress bar to reliably know how many lines we'll eventually have to erase (there are a couple of reasons for this; for example, the information about the terminal width often is unreliable). So, if we don't erase lines anyway, we can as well let the terminal break lines. -- Change-Id: Id20806e6d53bfeccc781200eeac96acf48a74b1d Reviewed-on: https://bazel-review.googlesource.com/#/c/3292 MOS_MIGRATED_REVID=119510906
* experimental UI: honor --cursesGravatar Klaus Aehlig2016-04-11
| | | | | | | | | | | | Bazel can be asked to uses colors, but not to use other curses options. In this case, the ExperimentalEventHandler cannot rely on the terminal to ignore all curses output; hence it has to actively refrain from using curses that move the cursor. -- Change-Id: I026edade4366a8c5a8e56d376e8a4603f5c73b92 Reviewed-on: https://bazel-review.googlesource.com/#/c/3291 MOS_MIGRATED_REVID=119439855
* experimental UI: use LoadingProgressReceiverGravatar Klaus Aehlig2016-04-07
| | | | | | | | | | | | Subscribe to the LoadingPhaseStartedEvent to get the LoadingProgressReceiver; use it to provide information about the loading progress. As this event will not be raised by the LegacyLoadingPhaseRunner, do not depend on this event and still produce a sensible status bar if it is never raised. -- Change-Id: I1db24ceaf7de4fc42d00b02f470066cb38c877b4 Reviewed-on: https://bazel-review.googlesource.com/#/c/3270 MOS_MIGRATED_REVID=119261675
* experimental UI: present SUBCOMMANDS in the scroll-back bufferGravatar Klaus Aehlig2016-03-31
| | | | | | | | | | | | | Treat SUBCOMMAND events the same way as ERROR/WARNING/INFO commands in the experimental UI: they provide information the user wants to look up later. As SUBCOMMAND events are only raised if that information is requested by the user, providing this information does run the risk over overwhelming the user with information. -- Change-Id: Ia7adeb2d5b92f18b8b88b026f790ac2af47b59d4 Reviewed-on: https://bazel-review.googlesource.com/#/c/3201 MOS_MIGRATED_REVID=118678085
* Signal that the help command does not buildGravatar Klaus Aehlig2016-03-31
| | | | | | | | | | In this way, we prevent the experimental UI from reporting about the number of actions (actually 0) currently running. -- Change-Id: Ic1c02d388f1928b8fe8d2d66dc14757b0213c43b Reviewed-on: https://bazel-review.googlesource.com/#/c/3180 MOS_MIGRATED_REVID=118580580
* Signal that clean does not buildGravatar Klaus Aehlig2016-03-30
| | | | | | | | | | | | | bazel clean never runs any actions, hence any message about running actions would confuse the user. Therefore, signal that clean is a non-building command so that the experimental UI knows not the report about progress of building. -- Change-Id: I193f199b052e990992359bc9efdbe34db397ac5f Reviewed-on: https://bazel-review.googlesource.com/#/c/3125 MOS_MIGRATED_REVID=118554435
* Signal that the query command does not buildGravatar Klaus Aehlig2016-03-24
| | | | | | | | | | | | This will tell the experimental UI not to produce updates on the build status and also pass through correctly STDOUT/STDERR events. In particular, the standard output is suitable for consumption by other tools. -- Change-Id: Ifffd445433a29df20f062a762fe6280229319196 Reviewed-on: https://bazel-review.googlesource.com/#/c/3123 MOS_MIGRATED_REVID=118024251
* Signal that the info command does not buildGravatar Klaus Aehlig2016-03-24
| | | | | | | | | | | | | | In the experimental UI, during build, STDOUT and STDERR events are reported as separate events, properly terminated by CR LF. After the completion of the build, however, STDOUT and STDERR are passed through byte by byte, to allow nicely formatted output. Info commands, however, do not build, so there is no event to signal end of build; hence report that fact directly to the UI. -- Change-Id: Ic236d33ee6e65637016370e15ed37e3d9494a258 Reviewed-on: https://bazel-review.googlesource.com/#/c/3122 MOS_MIGRATED_REVID=117934742
* Add an integration test for --experimental_uiGravatar Klaus Aehlig2016-03-15
Add end-to-end tests for very basic properties of the new experimental UI. - At some point during a successful build, we should see an N / M actions progress bar status indicator. - Curses are used to erase some lines. - On a successful test, PASS is written in green. - On a failed test, FAIL is written in red bold. -- Change-Id: I0130017949330882ca6b33552cd288286a4f5b6f Reviewed-on: https://bazel-review.googlesource.com/#/c/3080 MOS_MIGRATED_REVID=117230615
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 01:47:45 +0000