aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime
Commit message (Collapse)AuthorAge
* 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
* Allow modules to inject a custom AttributeContainer.Gravatar Janak Ramakrishnan2016-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | Rollback of commit cda4b4eae0c495a8f90f2a70a8db46e34062ee26. *** Reason for rollback *** Roll-forward with fixes (see ExternalPackageBuilder). *** Original change description *** Automated [] rollback of commit 178a3dfda8bf72abf22758597a90a4afb8eed181. *** Reason for rollback *** Broke ci.bazel.io. See #1234. *** Original change description *** Allow modules to inject a custom AttributeContainer. -- MOS_MIGRATED_REVID=122100417
* Flip --deep_execroot to default to trueGravatar Kristina Chodorow2016-05-11
| | | | | -- MOS_MIGRATED_REVID=121996611
* Print coverage.dat location always.Gravatar Googler2016-05-11
| | | | | -- MOS_MIGRATED_REVID=121960458
* RELNOTES: Use singular form when appropriate in blaze's test result summary ↵Gravatar Googler2016-05-10
| | | | | | | | | message. This fixes the output "Executed 1 out of 1 tests". -- MOS_MIGRATED_REVID=121949576
* 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
* Do not hard-code Blaze as product nameGravatar Klaus Aehlig2016-05-09
| | | | | | | | | ...use Constants.PRODUCT_NAME instead. Fixes #1244. -- Change-Id: Icdf07c5e0cdadc0e459708f13dae78f70b5ef026 Reviewed-on: https://bazel-review.googlesource.com/#/c/3580 MOS_MIGRATED_REVID=121819053
* Rollback of commit 178a3dfda8bf72abf22758597a90a4afb8eed181.Gravatar Damien Martin-Guillerez2016-05-06
| | | | | | | | | | | | | | | *** Reason for rollback *** Broke ci.bazel.io. See #1234. *** Original change description *** Allow modules to inject a custom AttributeContainer. -- MOS_MIGRATED_REVID=121658474
* Allow modules to inject a custom AttributeContainer.Gravatar Janak Ramakrishnan2016-05-04
| | | | | -- MOS_MIGRATED_REVID=121497233
* cpp: fix documentation wording for data members in GlobalVariablesGravatar Thiago Farina2016-05-04
| | | | | | | | | | | | Some had incorrect words, or were missing a word and the end period. Make it match with the descriptions in CommonCommandOptions.java. Add a short documentation comment to |restart_reason| field. -- Change-Id: Iac802eb3ed4f72dfd402e85d2098a5616b40a9de Reviewed-on: https://bazel-review.googlesource.com/3530 MOS_MIGRATED_REVID=121478703
* Redesign InfoItem to use classes instead of the InfoKey enum. This way the ↵Gravatar Luis Fernando Pino Duque2016-05-03
| | | | | | | | | InfoItems can now take parameters. -- MOS_MIGRATED_REVID=121379097
* Remove documentation for "abi" and "abi_deps".Gravatar Greg Estren2016-05-03
| | | | | | | | | These attributes are going away imminently. select() is the new abi_deps. -- MOS_MIGRATED_REVID=121294764
* In InvocationPolicyEnforcer#enforce, instead of just checking the direct ↵Gravatar Janak Ramakrishnan2016-05-02
| | | | | | | | | | | command to see if a flag policy applies, check whether the flag applies by seeing if its list of commands matches one of the commands in the hierarchy. This avoids the tedious and brittle specification of all commands that may use a flag, while providing better filtering out of inapplicable flags. RELNOTES: A FlagPolicy specified via the --invocation_policy flag will now match the current command if any of its commands matches any of the commands the current command inherits from, as opposed to just the current command. -- MOS_MIGRATED_REVID=121159131
* When we don't have an OutputService, precompute and cache the ↵Gravatar Nathan Harmata2016-05-02
| | | | | | | | | | | assumed-to-be-immutable filesystem type of output_base. When we do have an OutputService, defer computation of the OutputService's dynamic filesystem type until we actually need it at the start of a "build" or "test" command. This saves ~450us on each invocation, according to my benchmarks. -- MOS_MIGRATED_REVID=121156323
* Memoize the OptionsData per BlazeCommand.Gravatar Nathan Harmata2016-05-02
| | | | | | | | | This saves the cost of (1) collecting all Options classes and (2) getting all their @Option annotations. Note that there is no savings on reflection costs, since that's already memoized internally by OptionsParser. This saves ~250us per Blaze invocation. -- MOS_MIGRATED_REVID=121153156
* Precompute defaults package content to save ~milliseconds every time ↵Gravatar Janak Ramakrishnan2016-04-28
| | | | | | | | | BlazeRuntime#getDefaultsPackageContent is called. Thanks to nharmata for the suggestion. -- MOS_MIGRATED_REVID=120984951
* Remove repeated allowMissingInputs module check.Gravatar Janak Ramakrishnan2016-04-28
| | | | | -- MOS_MIGRATED_REVID=120962924
* Fix a race condition introduced in unknown commit (that is, the January of ↵Gravatar Lukacs Berki2016-04-26
| | | | | | | | | | | | | 2009!). If a "blaze clean --expunge" was run concurrently with another command (that was waiting for the lock), it's possible that the clean command deletes the lock file, the new server starts up, then the JVM shutdown hooks delete the PID files from the *new* server. There is still a slight possibility of a race condition if the lock is deleted then IOException occurs which prevents the BlazeShutdownException from being raised, but I'd rather not introduce another channel from command implementations to RPCServer to close that loophole. This issue was triggered by commit 5a78166ee4edbd295f5d5fdb94785025285e764b, after which the PID files for the new server are written a bit more early, thus increasing the time window in which the race condition can happen. -- MOS_MIGRATED_REVID=120805163
* Make gRPC mode honor --max_idle_secs.Gravatar Lukacs Berki2016-04-25
| | | | | -- MOS_MIGRATED_REVID=120699557
* 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
* Make the integration tests pass with gRPC client/server comms.Gravatar Lukacs Berki2016-04-21
| | | | | | | | | | | In particular: - Make a SIGINT to the server interrupt every command - Parse negative numbers on the command line correctly (std::stoi throws an exception, and I'd rather not start using C++ exceptions) - Use "bytes" for command line arguments instead of "string" in the client/server proto . This is more principled, although we pretend all arguments are strings all over the place and it works for "blaze run" mostly by accident. -- MOS_MIGRATED_REVID=120434432
* Assorted changes wrt. gRPC client/server comms:Gravatar Lukacs Berki2016-04-21
| | | | | | | | | - Actually make it work again (commit 00cfb7df61b1f3d9fac8ee29d92b315cbfe6d28f broke it, maybe I shouldn't send out changes in a hurry next time) - Rename --grpc_port to --command_port (it's a bit better name) - Do not send a kill signal to the server that can't be connected if we only connect to it to verify its presence -- MOS_MIGRATED_REVID=120418784
* Make client-provided options an rc sourceGravatar Klaus Aehlig2016-04-21
| | | | | | | | | | | | | | | The client provides information about whether the terminal is a tty, and which width the output should be formatted for. Passing this information as explicit command-line arguments has the disadvantage that it overrides any setting in configuration files. While usually there is no one-size-fits-all value for terminal width, it doesn't make sense either to have an option where the user cannot set a default. Fix this by providing the client options as least imported rc-source. This is a roll-forward of commit 044adedc70de040475443e52eb1a3c692159790e -- MOS_MIGRATED_REVID=120338148
* Allow executing input files in addition to output onesGravatar Brian Silverman2016-04-20
| | | | | | | | | | | | With remote repositories, it is useful to do this to execute an input file which isn't actually part of the source tree. Closes #984 -- Change-Id: Ic986ea9bbe88e0edb933939ce1d7a8b6ea9d6e88 Reviewed-on: https://bazel-review.googlesource.com/#/c/3030/ MOS_MIGRATED_REVID=120248102
* Block when another command is running on the server and not on the client ↵Gravatar Lukacs Berki2016-04-20
| | | | | | | when in gRPC mode. -- MOS_MIGRATED_REVID=120233121
* 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
* Do not start the AF_UNIX server when in gRPC mode.Gravatar Lukacs Berki2016-04-19
| | | | | | | Work towards #930. With this, it's conceivable that server mode works on Windows to some degree (I haven't tried, though, because there are many issues that need to be fixed) -- MOS_MIGRATED_REVID=120202037
* Module cleanup - don't hold on to stuff after the command completes.Gravatar Ulf Adams2016-04-18
| | | | | -- MOS_MIGRATED_REVID=120111522
* 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
* Inject the BlazeDirectories in SkyframeExecutor.Gravatar Ulf Adams2016-04-15
| | | | | | | | | The BlazeDirectories are also needed for loading the WORKSPACE file, so inject them as part of preparePackageLoading rather than in createConfigurations, which is too late. -- MOS_MIGRATED_REVID=119931633
* Add an afterCommand hook to AbstractBlazeQueryEnvironment.Gravatar Nathan Harmata2016-04-15
| | | | | -- MOS_MIGRATED_REVID=119868282
* Add the --grpc_port startup option and start a Java server if it's passed in.Gravatar Lukacs Berki2016-04-14
| | | | | | | | | | | | | Note that the presence of server/grpc_port does not guarantee that the server actually listens to it and we can't guarantee it, either, because it can always be kill -9'd. I haven't decided yet how the transition between AF_UNIX and gRPC will work. For now, I'm happy that we can start up a Java server. The way to get the kernel-chosen port is truly awful, but it is apparently impossible to do so in a different way: https://github.com/grpc/grpc-java/issues/72 -- MOS_MIGRATED_REVID=119828354
* 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
* Refactor BlazeWorkspace creation to happen after BlazeRuntime construction.Gravatar Ulf Adams2016-04-13
| | | | | | | | As part of that, move a BinTools and the WorkspaceStatusActionFactory to the BlazeWorkspace. -- MOS_MIGRATED_REVID=119633702
* 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
* 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
* 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: 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
* Properly use PrintStream in QueryCommand. PrintStream swallows all ↵Gravatar Nathan Harmata2016-04-11
| | | | | | | IOExceptions and so we need to check if any were encountered. -- MOS_MIGRATED_REVID=119417412
* Fix bug introduced by commit dc0fbb42ab22ab8f3205b0884069e1ffe03677c9 where ↵Gravatar Nathan Harmata2016-04-07
| | | | | | | | | | | | | a less specific option specification in a rc file could override a more specific option specification when there's a non-trivial Command hierarchy. A concrete example would be a "build --foo=1" line overriding a "test --foo=2" line for a "test" invocation. See the added test for more details. Also fix some typos in BlazeCommandDispatcherRcoptionsTest.java. Note that commit dc0fbb42ab22ab8f3205b0884069e1ffe03677c9 was rolled back in commit 417dad0f1e0d0ed4ccd5f8e52b49eb79937da49d which also incidentally rolled back commit 4f0fbe1b09333806cce76b75214e98c7684766e0. So this change is effectively a roll-forward of both of those, plus the bug fix, plus the typo fixes, and plus a documentation update. -- MOS_MIGRATED_REVID=119276218
* 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
* Rollback of commit dc0fbb42ab22ab8f3205b0884069e1ffe03677c9.Gravatar John Field2016-04-07
| | | | | | | | | | | | | | | | | | *** Reason for rollback *** Changed the semantics of local .blazerc handling, requiring a Blaze release rollback ([]). *** Original change description *** Make specific options win over common ones When specifying which command names to parse options for, given the command annotation, ensure that "common" comes first, so that it can be overridden by more specific options. -- MOS_MIGRATED_REVID=119227260
* Clean up FancyTerminalEventHandlerGravatar Googler2016-04-07
| | | | | -- MOS_MIGRATED_REVID=119051781
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-12 02:17:31 +0000