aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime/ExperimentalStateTracker.java
Commit message (Collapse)AuthorAge
* If --batch, --keep_going, --discard_analysis_cache, and the new ↵Gravatar janakr2017-03-31
| | | | | | | | | | | | | | | --noexperimental_enable_critical_path_profiling flags are all specified, then Bazel will delete Actions from ActionLookupValues as they are executed in order to save memory. Because an already-run action may output an artifact that is only requested later in the build, we need to maintain a way for the artifact to look up the action. But in most cases we don't need to keep the action itself, just its output metadata. Some actions unfortunately are needed post-execution, and so we special-case them. Also includes dependency change with description: Move action out of key. This keeps action references from polluting the graph -- actions are just stored in one SkyValue, instead of being present in SkyKeys. This does mean additional memory used: we have a separate ActionLookupData object per Action executed. That may reach ~24M for million-action builds. PiperOrigin-RevId: 151756383
* 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
* Make ExperimentalStateTracker aware of DownloadProgressEvents Gravatar Klaus Aehlig2017-03-02
| | | | | | | | | | | | In the experimental UI, to be able to report appropriately about ongoing downloads, we need to track their state, as updated by the DownloadProgressEvents. Do so. Also report on ongoing downloads in the progress bar. -- Change-Id: I668e963cd6da85ec598b23724066d366d465271f Reviewed-on: https://cr.bazel.build/9114 PiperOrigin-RevId: 148899297 MOS_MIGRATED_REVID=148899297
* ExperimentalStateTracker: make suffix gracefully handle negative lengthGravatar Klaus Aehlig2016-08-02
| | | | | | | | | | | | | | When requested to produce a suffix of a string of a string of a given length, gracefully handle the case where the requested length is negative---simply return the empty string in this case. While there, mark this static method as such; also increase visibility to default as it is generally useful and should be tested as an interface of this class. -- Change-Id: I821966f7ba3828809bc6d000358803c131740ec9 Reviewed-on: https://bazel-review.googlesource.com/#/c/4223 MOS_MIGRATED_REVID=129080284
* experimental UI: on failing tests, don't state "completed sucessfully"Gravatar Klaus Aehlig2016-06-29
| | | | | | | | | | | | | | Currently, if a build completes with tests failing, the final status message is "INFO: Build completed successfully, xxx actions". While technically correct, it might mislead the user to believing all tests have passed (especially when only looking at the status in the terminal title). Therefore, if a build completes with failing tests, mention the number of failed tests in the final status message. -- Change-Id: I9234fbfdf2ad43dd29af660966dde73bf0c9311a Reviewed-on: https://bazel-review.googlesource.com/#/c/3918 MOS_MIGRATED_REVID=126176452
* 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: also during loading produce a short progress barGravatar Klaus Aehlig2016-06-28
| | | | | | | | | | | | When writing the experimental state tracker is asked to produce a progress bar, it can be requested to have a one-line version. This one is used, e.g., if curses are not available and therefore it cannot be erased. Also honor that request, if reporting about loading progress. -- Change-Id: Ice3045fc86280e420b789a94b03427ff578f4a11 Reviewed-on: https://bazel-review.googlesource.com/#/c/3912 MOS_MIGRATED_REVID=126057511
* Unhide --experimental_ui_actions_shownGravatar Klaus Aehlig2016-06-27
| | | | | | | -- Change-Id: I1b8acc9dbd73ede3952a51f3f67b32e1b7e536a2 Reviewed-on: https://bazel-review.googlesource.com/#/c/3900 MOS_MIGRATED_REVID=125957281
* experimental UI: mention that we track the _running_ actionsGravatar Klaus Aehlig2016-06-27
| | | | | | | | | | | | The experimental UI shows the oldest still running actions as well as the total number of running actions. However, just presenting them as "X actions" is confusing for some users; so be more explicit and mention them as "X actions running". -- Change-Id: I26b8450690dc8b233271596d3c85e9c0924f7333 Reviewed-on: https://bazel-review.googlesource.com/#/c/3901 MOS_MIGRATED_REVID=125941605
* 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: 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
* experimental UI: when showing the last test, color-code its stateGravatar Klaus Aehlig2016-06-03
| | | | | | | | | | | The experimental UI also keeps track, in the progress bar, of the last test that completed. When using curses, use colors to indicate whether the test passed or not. -- Change-Id: Iaa01a773c3bbf534692ed21dd420596cb63e2585 Reviewed-on: https://bazel-review.googlesource.com/#/c/3752 MOS_MIGRATED_REVID=123871492
* 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
* experimental UI: group test actions by labelGravatar Klaus Aehlig2016-05-25
| | | | | | | | | | | When reporting about actions that are still running, groups those belonging to the same test. In this way, more useful information can be presented in the progress bar, instead of wasting a whole line for a single shard. -- Change-Id: Id1f5a0595767906d6a75f6533be54f3c262ddd67 Reviewed-on: https://bazel-review.googlesource.com/#/c/3646 MOS_MIGRATED_REVID=123097744
* experimental UI: improve message shorteningGravatar Klaus Aehlig2016-05-20
| | | | | | | | | | | | | | | | | When a progress message has to be shortened, as it does not fit in a line in the progress bar, add a new first attempt: if the message the path implicit to the label, only shorten that path within the message (if that gets short enough, leaving a reasonable part of the path); usually, the additional information is more useful than having a longer part of the path present. While there, also fix incorrect length computation in a different case of message shortening. -- Change-Id: Ied80e03cace1b249fc0f4e11bce41f2b4207b6ad Reviewed-on: https://bazel-review.googlesource.com/#/c/3670 MOS_MIGRATED_REVID=122818198
* experimental_ui: show number of packages loaded during analysisGravatar Klaus Aehlig2016-05-19
| | | | | | | | | | | After the initial loading phase, further packages are loaded during analysis. Show in the experimental UI the total number of packages loaded during analysis phase to indicate at least some progress. -- Change-Id: I345c6f806591e70e4397fc3e3365718dde95d7d2 Reviewed-on: https://bazel-review.googlesource.com/#/c/3645 MOS_MIGRATED_REVID=122728719
* 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
* 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: 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
* ExperimentalStateTracker: add a short version of the progress barGravatar Klaus Aehlig2016-04-11
| | | | | | | | | | | | When bazel is used without curses, every status message ever written will never be deleted and, instead, stick in the log. To keep the output manageable in this case, provide a one-line progress bar to be used in this case. -- Change-Id: Ia0f9619d406e676f88ff536617a56fd4990cb51e Reviewed-on: https://bazel-review.googlesource.com/#/c/3294 MOS_MIGRATED_REVID=119520912
* experimental UI: squeeze dots in last sample actionGravatar Klaus Aehlig2016-04-11
| | | | | | | | | | | | When showing the earliest started actions in the progress bar of the experimental UI, it is a wasted line to use a whole line just to show dots indicating that more actions are running; instead, just put the dots on the same line as the last action. -- Change-Id: I37fcb654f689786ab522036b563409b15b85437f Reviewed-on: https://bazel-review.googlesource.com/#/c/3290 MOS_MIGRATED_REVID=119439830
* 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
* experimental UI: show run-time for long-running actions in the progress barGravatar Klaus Aehlig2016-04-04
| | | | | | | | | | | | Currently, the progress bar shows the 3 earliest started still running actions. While this might give some indication about which actions delay the build process, it lacks quantitative information about how long the delay is. By adding the current run time to the progress bar, at least some quantitative information is provided. -- Change-Id: Ib90eda67d87384a4372cda7779a09a44cea2b8dd Reviewed-on: https://bazel-review.googlesource.com/#/c/3205 MOS_MIGRATED_REVID=118933973
* 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
* Add semantic tests for ExperimentalStateTrackerGravatar Klaus Aehlig2016-03-14
| | | | | | | | | | | | | | | | | | | | | | | Now that the experimental UI has the first properties we want to keep in the long run, add a test asserting the following semantic properties. - Whenever only one action is running, it is shown somehow in the progress bar. - Completed actions should not be shown in the progress bar. - The earliest-started still running action should be visible in the progress bar. While there, also drop the assumption in the ExperimentalStateTracker that the ExecutionProgressReceiverAvailableEvent has to come before any actions that has not been finished yet. -- Change-Id: Ica52eb12546703e4f8f9d9c64928208621d19ced Reviewed-on: https://bazel-review.googlesource.com/#/c/3048 MOS_MIGRATED_REVID=117121300
* experimental UI: also remember the currently running actionsGravatar Klaus Aehlig2016-03-04
| | | | | | | | | | | | By not only having a unique identifier for each running action, but also remembering additional information about the actions, in particular the action itself, we can provide a more meaningful description of the currently running actions in the progress bar. -- Change-Id: I34760a437bf731f057162ca4d08368fe35d4bc71 Reviewed-on: https://bazel-review.googlesource.com/#/c/3045 MOS_MIGRATED_REVID=116349484
* experimental UI: use the progress receiverGravatar Klaus Aehlig2016-03-04
| | | | | | | | | | To improve reporting, in particular about the actions to carry out, make use of the ExecutionProgressReceiver. -- Change-Id: I9295199e4c6d9626a193b48b8f332ab2af8e3014 Reviewed-on: https://bazel-review.googlesource.com/#/c/3044 MOS_MIGRATED_REVID=116347930
* Keep track of actions currently runningGravatar Klaus Aehlig2016-02-25
| | | | | | | | | | | | | Subscribe to start and completion events of actions to keep track of which actions are currently running. In the progress bar show up to 3 actions currently running, giving preference to the ones that started the most early. Also keep track of completion of analysis and build. -- Change-Id: I9183a84821abca85e2331baa059e1f636d756caf Reviewed-on: https://bazel-review.googlesource.com/#/c/3016 MOS_MIGRATED_REVID=115549337
* Add a state tracker and show a progress barGravatar Klaus Aehlig2016-02-25
Add a state tracking class that is capable of keeping track of the internal state of the computation. Use it to provide a status bar at the lower end of the terminal. -- Change-Id: I39c17a80a238b3bc0d94527652b56a793f580d02 Reviewed-on: https://bazel-review.googlesource.com/#/c/3014 MOS_MIGRATED_REVID=115538418
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 16:54:57 +0000