| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old implementation cached the timestamp when the workspace status
action is created, which may be much earlier then the action gets
executed and end up leaving stale timestamp in volatile-status.
Close #1103
--
Change-Id: I0f09ac66681a134aeb10daf2455f3c3f98d8cd8f
Reviewed-on: https://bazel-review.googlesource.com/#/c/3221/
MOS_MIGRATED_REVID=119930493
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119920313
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119902657
|
|
|
|
|
|
|
|
|
| |
cc_* targets, CcLibraryHelper will not process objc source files, which may have been provided accidentally though a filegroup.
Note: This is note intended to prevent illegal sources for cc_* targets - that will be implemented in a different CL. This will involve making changes to filtering occuring in CcCommon, which for now will permit objc source.
--
MOS_MIGRATED_REVID=119897621
|
|
|
|
|
|
|
|
|
| |
It is probably more efficient in the common case where the Iterable is a collection. String and list handling in Skylark results in a *lot* of calls to this method, and the use of addAll should reduce the amount of copying and GCing that needs to occur.
An alternative would be to change the underlying type of SkylarkList from ArrayList to LinkedList, which would reduce the copying and GCing due to list concatenation even more. There is probably a downside to that but it is not clear if it is significant.
--
MOS_MIGRATED_REVID=119891128
|
|
|
|
|
|
|
| |
processing.
--
MOS_MIGRATED_REVID=119873729
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119868282
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119848254
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119843072
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119832385
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Contributor finds some bugs and after fixing some bugs there are more bugs to fix now.
*** Original change description ***
Mount whole directories into the sandbox when possible
This halves the overhead with sandboxing enabled vs disabled for a test
that basically only mounts a bunch of files out of a directory, and
slows that same test with a single extra file added to the directory
(but not mounted) by only ~4%.
The test is <https://gist.github.com/bsilver8192/10527a862ce16bb7f79a>
with 30000 inputs moved to a subdirectory and on...
***
ROLLBACK_OF=119138157
--
MOS_MIGRATED_REVID=119828267
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119813568
|
|
|
|
|
|
|
| |
Remove ArtifactFile, which is rendered obsolete by TreeFileArtifact.
--
MOS_MIGRATED_REVID=119789154
|
|
|
|
|
|
|
| |
skylark native access to ObjcProvider instances.
--
MOS_MIGRATED_REVID=119782586
|
|
|
|
|
|
|
|
|
| |
third_party.
I'm confused that Bazel has the concept of third_party, but as long as it does, let's exploit it.
--
MOS_MIGRATED_REVID=119779306
|
|
|
|
|
|
|
| |
rolled back in commit 1250fdac4c7769cfa200af8b4f9b061024356fea. There was nothing wrong with that change.
--
MOS_MIGRATED_REVID=119756383
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119755803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
src/main/java/com/google/devtools/build/lib/exec/SymlinkTreeHelper.java:
enable --windows_compatible flag on Windows to make build-runfiles.exe work.
scritps/bootstrap/compile.sh:
--windows_compatible will also be passed to a dummy build-runfiles.exe defined in complie.sh.
Which is actully a batch script, modify it to make it work.
-----
With the changes above, we are able to build bazel with bazel. But when you try to
run ./compile.sh compile /path/to/bazel again without clean up tmp directory, it will fail with
a permission deny error. The reason seems to be that you can't use build-runfile.exe to build the
same hard link twice, still trying to solve that.
--
Change-Id: I93340b1ba9fa415f6db963b106e264799e33ede3
Reviewed-on: https://bazel-review.googlesource.com/#/c/3334
MOS_MIGRATED_REVID=119751076
|
|
|
|
|
|
|
| |
RELNOTES: java_import now allows its 'jars' attribute to be empty.
--
MOS_MIGRATED_REVID=119749103
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
rules.
--
MOS_MIGRATED_REVID=119737046
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
c++ rule implementation backend and an OSX crosstool.
--
MOS_MIGRATED_REVID=119660101
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119655452
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119653212
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
--sandbox_debug and --verbose_failures are on. See discussion in #1049.
RELNOTES:
--
MOS_MIGRATED_REVID=119635080
|
|
|
|
|
|
|
|
| |
As part of that, move a BinTools and the WorkspaceStatusActionFactory to the
BlazeWorkspace.
--
MOS_MIGRATED_REVID=119633702
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119631623
|
|
|
|
|
|
|
| |
The code doesn't do anything yet and it's unused code for now. This change only serves to add all the necessary dependencies to BUILD files that gRPC needs.
--
MOS_MIGRATED_REVID=119628697
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
--
MOS_MIGRATED_REVID=119625653
|
|
|
|
|
|
|
|
| |
The cast to Label can never succeed for a configured target node, so this
code could never have been executed (or we'd see crashes at this location).
--
MOS_MIGRATED_REVID=119615022
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119599941
|
|
|
|
|
|
|
|
|
| |
come up a couple of times.
RELNOTES:
--
MOS_MIGRATED_REVID=119578035
|
|
|
|
|
|
|
| |
point to the workspace root.
--
MOS_MIGRATED_REVID=119558172
|
|
|
|
| |
MOS_MIGRATED_REVID=119557016
|
|
|
|
|
|
|
|
| |
Turbine now leaves enforcement of strict deps to JavaBuilder. Compile-time
dependencies will still be collected as long as --output_deps is set.
--
MOS_MIGRATED_REVID=119551363
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119533501
|
|
|
|
|
|
|
| |
requests wherever we can.
--
MOS_MIGRATED_REVID=119531512
|
|
|
|
|
|
|
|
|
| |
BadWorkspaceFileException and BadPreludeFileException.
BadWorkspaceFileException and BadPreludeFileException are not doing anythings special rather than providing a custom message. Replace them by using NoSuchTargetException directly.
--
MOS_MIGRATED_REVID=119530878
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
6f15335 Make labels in .bzl files in remote repos resolve relative [...]
introduced a Frame#setLabel which is documented to create a new Frame
but instead modifies the existing one. This results in the global
environment being modified in-place.
I've been seeing some strange errors about not finding various packages
in the wrong repositories which seems to be fixed by this change.
--
Change-Id: I9b8521e50f45cfd385b20491315904ff0e24dcf6
Reviewed-on: https://bazel-review.googlesource.com/#/c/3300
MOS_MIGRATED_REVID=119529142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
IOExceptions and so we need to check if any were encountered.
--
MOS_MIGRATED_REVID=119417412
|