Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bazel slow and flaky at HEAD on Travis CI #1494

Closed
jart opened this issue Jul 9, 2016 · 5 comments
Closed

Bazel slow and flaky at HEAD on Travis CI #1494

jart opened this issue Jul 9, 2016 · 5 comments

Comments

@jart
Copy link
Contributor

jart commented Jul 9, 2016

Something mysterious happened about 25 days ago with Bazel HEAD. It caused Closure Rules' Travis CI tests to go from taking 15 minutes to 45 minutes.

screen shot 2016-07-09 at 12 57 56 am

Travis builds at HEAD are also very frequently failing, because Travis is kill 9'ing Bazel process. Probably due to exceeding memory.

Here's the build history:

https://travis-ci.org/bazelbuild/rules_closure/builds
@jart
Copy link
Contributor Author

jart commented Jul 9, 2016

It's also worth mentioning that Closure Rules enabled testing Bazel at HEAD exactly 25 days ago. So whatever happened, must have happened somewhere between 0.3.0 and 25 days ago. (See my .travis.yml file for reference.)

@jart jart changed the title Bazel slow and flaky at HEAD past 25 days Bazel slow and flaky at HEAD Jul 9, 2016
@jart jart changed the title Bazel slow and flaky at HEAD Bazel slow and flaky at HEAD on Travis CI Jul 9, 2016
@damienmg
Copy link
Contributor

I am not seeing > 15min build. Each 45min build is 3 runs of Bazel. That's a travis issue.

@kchodorow
Copy link
Contributor

It looks like
bazelbuild/rules_closure@401aa58
changes the .travis.yml to run three different builds, instead of just
one. It looks like the elapsed time is still just 15 minutes:

​Source: https://travis-ci.org/bazelbuild/rules_closure/builds/137545464

On Sat, Jul 9, 2016 at 1:07 AM, Justine Tunney notifications@github.com
wrote:

It's also worth mentioning that Closure Rules enabled testing Bazel at
HEAD exactly 25 days ago. So whatever happened, must have happened
somewhere between 0.3.0 and 25 days ago. (See my .travis.yml
https://github.com/bazelbuild/rules_closure/blob/master/.travis.yml
file for reference.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1494 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AABCku8tfjTSZUVhpYDrBjgNzqRYrRzOks5qTyyEgaJpZM4JIiyT
.

@damienmg
Copy link
Contributor

Closing this issue since it is not from Bazel

@jart
Copy link
Contributor Author

jart commented Jul 11, 2016

I'm sorry, I explained this incorrectly. The build itself takes like 10 minutes. What's happening is it appears to be using a lot more memory at head. So Travis ends up kill 9'ing one of the processes.

screen shot 2016-07-11 at 6 51 30 am

Did something change in the way that Bazel schedules processes? Maybe Bazel is exceeding the resource limits I gave it?

Wyverald pushed a commit that referenced this issue Mar 8, 2022
@oquenchil
Correct error runfiles cc_shared_library (#14998)
78f0311 
Fix runfiles in cc_shared_library

#1494 misses a key part which was to actually add the precompiled libraries to the runfiles provider. There was a test but this used a cc_binary which gave the false sense of things working correctly since the cc_binary is able to get the runfiles from the CcInfo and add it itself. Changed test to use a py_test instead.

Cherrypick of 426188c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kchodorow @jart @damienmg