aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime/ExperimentalEventHandler.java
Commit message (Collapse)AuthorAge
* 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
* experimentalUI: show date, if timestamps are enabledGravatar Klaus Aehlig2017-05-12
| | | | | | | | | | | While builds usually finish in a single day, for console logs (especially those collected on a CI system) it is still useful to know the date they where collected on. So, if --show_timestamps is given, show a line with the current date at the beginning of the build to not lose the information due to the shorter time stamps, compare #2989. Change-Id: Ief2ae011cdb4de7ac5d5a9acd4d200913220b2a3 PiperOrigin-RevId: 155859302
* experimental_ui: improve --show_timestamp handlingGravatar Klaus Aehlig2017-05-05
| | | | | | | | | | Move the position of the timestamp to the beginning of the line to have a more readable log. Also, show the timestamp for progress as well. While there, reduce timestamp to second precision, to reduce noise. Change-Id: Ibfa6caca2e0d207f54e3660bccbf894bba3c5ae3 PiperOrigin-RevId: 155181731
* Automated g4 rollback of commit d9fea57268ff01c001fbcbdc2bd057c86c362e6f.Gravatar buchgr2017-04-25
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Rollforward with fix for test flakiness. BEP transport closed events are delivered via their own threadpool and thus might not have been sent immediately. BuildEventStreamerTest#testSimpleStream now waits for a bit until the event has been delivered. I ran the test with --runs_per_test=1000 several times and had no further failures. *** Original change description *** Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082. *** Reason for rollback *** Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000. RELNOTES: None PiperOrigin-RevId: 154170833
* Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082.Gravatar ajmichael2017-04-25
| | | | | | | | *** Reason for rollback *** Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000. RELNOTES: None PiperOrigin-RevId: 154090559
* BEP: Show protocol upload in the UIGravatar buchgr2017-04-24
| | | | | | | | | | | | | | | | | | | | | | The BEP (build event protocol) upload may at times take longer than the build itself. This is especially true for cached builds, where there is little build work, but the protocol still needs to be uploaded. In this case the bazel UI will now display that it's waiting for BEP upload, both in the current and the new experimental UI (--experimental_ui). When executing a run command, blaze waits for the BEP upload to finish before it runs the target. Major Modifications: - The BuildEventTransport interface now also has a name() method that returns a string. When waiting for a transport to finish the BEP upload, this string is displayed in the UI. - The BuildEventStreamer now emits two new events AnnounceBuildEventTransportsEvent and BuildEventTransportClosed on the event bus. This is how the experimental UI is informed about BEP upload progress. RELNOTES: None PiperOrigin-RevId: 154052401
* Experimental UI: increase progress rate limit with time, if no in-place updateGravatar Klaus Aehlig2017-04-10
| | | | | | | | | | In the experimental UI, increase the rate limit for updates to the progress bar over time, if it cannot be updated in place. In this way, we can get snappy first progress descriptions, while not overwhelming the user with too many progress messages. Change-Id: I769f1a9ef4304b613d40ece42b87df22881549cd PiperOrigin-RevId: 152502295
* 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
* Abstract from DownloadProgressEvent to generic FetchProgress Gravatar Klaus Aehlig2017-03-10
| | | | | | | | | | | In this way, we can easily add other fetch-like events to be reported in a similar way as plain downloads. -- Change-Id: I518df5ba27b6593eca98d30407b582f509a52aeb Reviewed-on: https://cr.bazel.build/9313 PiperOrigin-RevId: 149655918 MOS_MIGRATED_REVID=149655918
* Post DownloadProgressEvents in ProgressInputStream Gravatar Klaus Aehlig2017-03-03
| | | | | | | | | | | In this way, the experimental UI will report about the progress of downloads. Fixes #2563. Fixes #1260. -- Change-Id: I034e0f2bc8df0a1f46b28298d3d1fccc8daaaded Reviewed-on: https://cr.bazel.build/9115 PiperOrigin-RevId: 149013682 MOS_MIGRATED_REVID=149013682
* Use guava Uninterruptibles#joinUninterruptibly utility method instead of ↵Gravatar Janak Ramakrishnan2016-08-22
| | | | | | | rolling our own in ExperimentalEventHandler. -- MOS_MIGRATED_REVID=130935928
* ExperimentalEventHandler: narrow scope of synchronized blocksGravatar Klaus Aehlig2016-08-02
| | | | | | | | | | | | | | | | ...to in particular never own a lock while waiting for the update thread to finish. This avoids a deadlock when the update thread tries to enter the synchronized part of doRefresh while the thread trying to stop the update thread holds the lock. Also renable experimental_ui_test now that the race condition leading to the deadlock is fixed. The absence of flakiness has been verified by running the test locally 100 times. Fixes #1560. -- Change-Id: I5d85b347e6cb7a1da8d5a724d6f9cd7461e33e5b Reviewed-on: https://bazel-review.googlesource.com/#/c/4225 MOS_MIGRATED_REVID=129079398
* ExperimentalEventHandler: avoid recursive starting of the updateThreadGravatar Klaus Aehlig2016-08-02
| | | | | | | | | | | | | | | | Break the situation where an update thread tries to start another update thread early, by telling the doRefresh method when it is called from within an update thread. While no second thread would be started in this case anyway (as the global variables indicate that a thread is already in existence), a lock is still required for this step, which can cause all kinds of problems. Note that we don't have to worry about the update thread being about to be stopped in that moment, as only global events indicating completion stop the update thread. -- Change-Id: Ib025ba2b12bcd339c590593213eeedfd9cb230d3 Reviewed-on: https://bazel-review.googlesource.com/#/c/4224 MOS_MIGRATED_REVID=129077891
* Add a final event on the event busGravatar Klaus Aehlig2016-07-11
| | | | | | | | | | | | | Add an event to the event bus that is guaranteed to come after the completion of the command. Listeners can use this event to clean up any resources that still need to be cleaned up. As first customer, add the ExperimentalEventHandler so that it is guaranteed not to leak the update thread. -- Change-Id: Ia20bae8a00541aa1338e49f74a7320ac098ab71d Reviewed-on: https://bazel-review.googlesource.com/#/c/4011 MOS_MIGRATED_REVID=126909844
* ExperimentalEventHandler: remove deadlock in update threadGravatar Klaus Aehlig2016-07-08
| | | | | | | | | | | | | | | | | When the progress bar has to be updated, but we cannot do so immediately, e.g., due to rate limiting, we start a thread to do this eventually (the "update thread"). That thread gets stopped if either we realize during an update of the progress bar that it is no longer needed, or if we get informed about the completion of the build. Now, since the update thread does updates of the progress bar (that is its whole purpose) it can get the duty to stop itself. To avoid the deadlock when the thread there blockingly waits for itself to terminate, just skip that termination and let the update thread run till the end of the build. -- Change-Id: Iba08806f5e416f1fa1825969eceaf6cf54c24e6c Reviewed-on: https://bazel-review.googlesource.com/#/c/4010 MOS_MIGRATED_REVID=126906395
* Experimental UI: make stopUpdateThread() more insistingGravatar Klaus Aehlig2016-07-06
| | | | | | | | | | | | | | | | | The stopUpdateThread() method tries to stop the update thread by calling the interrupt() and join() methods on that thread. When getting interrupted while waiting for the thread to join, do not ignore the exception, instead try again to make sure we don't leave that method before the other thread is actually stopped. While there, also clean up the synchronized blocks for the thread handling: all blocks that handle multiple global variables like buildComplete, updateThread, etc, are synchronized while the actual thread-manipulating operations are outside those blocks. -- MOS_MIGRATED_REVID=126679343
* experimental UI: enforce a minimal progress rate limiting if curses unavailableGravatar Klaus Aehlig2016-07-01
| | | | | | | | | | | | | | | | | | If the progress bar cannot be updated in place, every additional writing of the progress bar clutters up the log. Of course, this could be controlled by adding --show_progress_rate_limit or even --noshow_progress options to the invocation; however, it turns out that users expect a bazel to just automatically reduce its output rate. Therefore, specify a minimal value for the progress rate limit of 2 seconds if the progress bar cannot be updated in place. Also, increase the time rate for purely time-based updates to 20s in this case. Moreover, only automatically redraw the progress bar after an INFO/WARNING/... message, if it can be updated in place. -- Change-Id: I7d06aa04acec457ec0a5d20ac32ede4cf80f7170 Reviewed-on: https://bazel-review.googlesource.com/#/c/3944 MOS_MIGRATED_REVID=126387987
* ExperimentalEventHandler: remove unnecessary inheritanceGravatar Klaus Aehlig2016-06-30
| | | | | | | | | | | | | The ExperimentalEventHandler uses no functionality of BlazeCommandEventHandler, hence there really is no need whatsoever for ExperimentalEventHandler to be a subclass of BlazeCommandEventHandler. So, remove this inheritance to clean up our class hierarchy; instead let the ExperimentalEventHandler just implement the EventHandler interface. -- Change-Id: I504f727190a12882dd8b7c37811a821e3ba50400 Reviewed-on: https://bazel-review.googlesource.com/#/c/3926 MOS_MIGRATED_REVID=126282974
* Make experimental UI resistent to late-reported eventsGravatar Klaus Aehlig2016-06-29
| | | | | | | | | | | | | Sometimes the event reporting the completion of the last action can, effectively, overtake the event reporting the completion of last action. To avoid late writing to the output stream don't start the update thread after the completion of the build is reported. There is nothing to update then any more anyway. -- Change-Id: Ibbb6d025635a9daa233c2b28ca64a1ae4896ce47 Reviewed-on: https://bazel-review.googlesource.com/#/c/3922 MOS_MIGRATED_REVID=126182576
* 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: flush buffersGravatar Klaus Aehlig2016-06-24
| | | | | | | | | At the end of the build (or when realizing that there will be no build phase), the experimental UI drops into full streaming mode. When doing so, do not forget to flush all buffered incomplete lines for stdout and stderr. -- MOS_MIGRATED_REVID=125770854
* experimental UI: consider progress bar refreshed on every redrawGravatar Klaus Aehlig2016-06-23
| | | | | | | | | | | | | | | | | Whenever the UI has to write a line to the progress buffer, it removes the progress bar, write the line and re-adds the progress bar. Of course, the re-added progress bar is the one that represents the up-to-date state at the time of it being re-added. Therefore, this also is a refresh of the progress bar. So update the time stamp tracking the last refresh. In this way rate-limits on refreshes are honored more correctly; also, requirements of the progress bar having to be refreshed after a certain point in time that have been fulfilled by that implicit refresh are recognized as such, keeping the output less flickering. -- Change-Id: I44bcd85a149cb88fcde126119100a6e1ff1ba45d Reviewed-on: https://bazel-review.googlesource.com/#/c/3873 MOS_MIGRATED_REVID=125664608
* experimental UI: after analysis summarize the work done thereGravatar Klaus Aehlig2016-06-23
| | | | | | | | | | | | | At the end of the analysis phase, show the amount of work done during this phase (e.g., number of packages loaded) in a way similar to the last progress message shown for loading. In this way, users will over time learn the number of packages their project depends on; thus the progress shown during loading will become more meaningful to them. -- Change-Id: If56fab5704c419be988e55f0c1705b3732c11369 Reviewed-on: https://bazel-review.googlesource.com/#/c/3872 MOS_MIGRATED_REVID=125656896
* Add an option for the number of actions shown in the experimental UIGravatar Klaus Aehlig2016-06-21
| | | | | | | | | | | | | | Currently, the experimental UI always shows the 3 oldest, still running actions. While this seems a reasonable default, some users requested to be able to change the number of actions shown. Hence replace the hard-coded value by a flag. While there, also fix an off-by-one error in deciding when to put the ellipsis symbol. -- Change-Id: I037d208360fa1d3f100c99ab1ab1f5fc140138ac Reviewed-on: https://bazel-review.googlesource.com/#/c/3811 MOS_MIGRATED_REVID=125427168
* 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
* experimental UI: delay updates after action completionGravatar Klaus Aehlig2016-06-20
| | | | | | | | | | | | | Very often, when an action completes, a new one is started directly afterwards. With this in mind, delay the refresh after the completion of an action as long as acceptable by the refresh rate limiting. If indeed an action starts within that time, we have replaced a double refresh of the progress bar by a single one, thus make it appear less flickering. -- Change-Id: I0e9143d6bba9929265ad2b6a3699486a1d5b3b2b Reviewed-on: https://bazel-review.googlesource.com/#/c/3823 MOS_MIGRATED_REVID=125165516
* experimental UI: also report the strategy of running actionsGravatar Klaus Aehlig2016-06-20
| | | | | | | | | | In the experimental UI, for the running actions also report their strategy. This will give a more complete picture of what Bazel is currently doing. -- Change-Id: I9553c952ed494e0db225b2a1ae5e8eba00f68617 Reviewed-on: https://bazel-review.googlesource.com/#/c/3820 MOS_MIGRATED_REVID=125162808
* 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: not only report errors, but also failures immediatelyGravatar Klaus Aehlig2016-06-09
| | | | | | | | | | | | When a user is running a test with lots of runs (e.g., to debug flakyness), it is useful to immediately see individual failures and not wait for the summary of tests. Therefore, report failure events just like errors in the scrollback buffer. -- Change-Id: If32d1201f59cec75d99d18a50fc881c3596c3081 Reviewed-on: https://bazel-review.googlesource.com/#/c/3770 MOS_MIGRATED_REVID=124437705
* ExperimentalEventHandler: fix off-by-one errorGravatar Klaus Aehlig2016-06-08
| | | | | | | | | | | | | | | | | | Java's Arrays.copyOfRange expects as "to" argument the index of the first character not to be copied. As indices start with 0, the first index outside the array is, in fact, the length itself (and not one more than the length). This off-by-one error so far never caused any problems, as Arrays.copyOfRange is guaranteed to accept arbitrary large "to" values and helpfully pads with 0-bytes. As 0-bytes are not shown on most terminals, the output still looked correct. However, that off-by-one error did mess up the output for users of the --experimental_show_artifacts flag. -- Change-Id: I135ff720740db5c224a47668fc7513cbb7110f9f Reviewed-on: https://bazel-review.googlesource.com/#/c/3771 MOS_MIGRATED_REVID=124332337
* 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
* ExperimentalEventHandler: narrow synchronization blocksGravatar Klaus Aehlig2016-04-25
| | | | | | | | | | | In particular, do not own a lock while waiting for another thread---especially not the update thread that might be waiting for the very lock were holding. -- Change-Id: I46aef3585b712e25cd4317004eacd8b48557a341 Reviewed-on: https://bazel-review.googlesource.com/#/c/3462 MOS_MIGRATED_REVID=120686232
* experimental UI: avoid empty lines between one-line FAILURE notesGravatar Klaus Aehlig2016-04-18
| | | | | | | | | | | | | | When reporting a multi-line test-failure message (the test that failed, plus the paths to the log files) to the scrollback buffer, it makes sense to end this whole block by an empty line. If, however, the test failure does not report any logs (e.g., if the build was interrupted), the next scroll-back buffer line can follow immediately to keep the scroll-back buffer more compact. -- Change-Id: I59d8ba9416d0a9bcbc8d959fee21cc94fa89018e Reviewed-on: https://bazel-review.googlesource.com/#/c/3386 MOS_MIGRATED_REVID=120108504
* Make ExperimentalStateTracker aim for target widthGravatar Klaus Aehlig2016-04-18
| | | | | | | | | | | | Optionally support a target width for the experimental state tracker; if given, it will try to produce a status bar with lines shorter than that limit, if possible, so that the status bar does not have to be broken. -- Change-Id: Ic5843285300ec10cf3e21b9b7402a6557f6bdb5e Reviewed-on: https://bazel-review.googlesource.com/#/c/3374 MOS_MIGRATED_REVID=119954289
* experimental UI: only redraw progress bar after event in curses modeGravatar Klaus Aehlig2016-04-14
| | | | | | | | | | | Whenever an event has to be reported to the scroll-back buffer, the old progress bar has to be removed first. Afterwards, it is redrawn. In a setting without cursor control, this, however, litters the log with lots status bars. Therefore, only redraw the progress bar after an event if cursor control is available. Note that the refresh thread will eventually ensure an up-to-date progress bar anyway. -- MOS_MIGRATED_REVID=119737382
* 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: Keep track of completed testsGravatar Klaus Aehlig2016-04-14
| | | | | | | | | | | When running tests, a useful information to know is the number of tests that have passed and failed already. Hence subscribe to the relevant events and provide this information in the progress bar as well. -- Change-Id: I6fabec3f4585500f096b820dbbd5e8e6897647fa Reviewed-on: https://bazel-review.googlesource.com/#/c/3350 MOS_MIGRATED_REVID=119727962
* experimental UI: ignore refresh limit on final progress-bar changeGravatar Klaus Aehlig2016-04-13
| | | | | | | | | | | The last version of the status bar will drop into the scroll-back buffer. Hence it should really represent the final state. To achieve this, ignore the refresh limit on the progress bar for its final update. -- Change-Id: I50b327dca80c12c9373e59a8702063369b18c461 Reviewed-on: https://bazel-review.googlesource.com/#/c/3333 MOS_MIGRATED_REVID=119637626
* 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
* 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: update progress bar on progress eventsGravatar Klaus Aehlig2016-04-05
| | | | | | | | | | | In the experimental UI, use progress events as an occasion to update the progress bar. However, to avoid unnecessary noise, only do so, if the progress bar potentially changes with time. -- Change-Id: I9bee093c29e0eb50e7fcce2fa6e941a02d615def Reviewed-on: https://bazel-review.googlesource.com/#/c/3206 MOS_MIGRATED_REVID=118944208
* Pass through the clock to the ExperimentalStateTrackerGravatar Klaus Aehlig2016-04-04
| | | | | | | | | | In this way, the ExperimentalStateTracker has access to all the information needed to provide information about the run-time of currently running actions. -- Change-Id: I0f4e48f39e9ebe63555e4bb1d70df2a6dbb65430 Reviewed-on: https://bazel-review.googlesource.com/#/c/3204 MOS_MIGRATED_REVID=118929758
* 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
* experimental UI: don't update progress bar after build for INFOGravatar Klaus Aehlig2016-03-30
| | | | | | | | | | | | | | | | | | | | | As explained in commit 37f3e9ee, after completion of the build, there is no need any more to update the progress bar. Instead, its last line, if any, can just float into the scroll-back buffer. From then on, STDOUT and STDERR events are just passed through. Do so as well for any late INFO, WARNING, or ERROR events. This will allow avoiding pointless messages in commands like 'bazel clean' (the patch removing those messages will also provide an appropriate integration test). Unfortunately, to make this work properly, we must ensure that both event handlers get informed about the fact that we have a no-build command. To do this, we register the event handler with the intended IO stream on the event bus, as well as a passively observing variant of the event handler that has direct acces to the full output stream. -- Change-Id: I148dc0065b6343e4a2a225b2d4fa615b4f720ff5 Reviewed-on: https://bazel-review.googlesource.com/#/c/3124 MOS_MIGRATED_REVID=118444275
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 21:55:41 +0000