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.

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

Can you help me understand why running buildifier via Bazel takes so long? #744

Open
ghost opened this issue Nov 21, 2019 · 4 comments
Open

Comments

@ghost
Copy link

ghost commented Nov 21, 2019

It appears like the protoc targets necessary to build buildifier go stale and I'm not quite sure why this is happening. It makes running buildifier via bazel very slow if you're only running it every ~5-10 minutes

@ghost ghost changed the title Can you help me understand why running buildifier via Bazel takes to long? Can you help me understand why running buildifier via Bazel takes so long? Nov 21, 2019
@pcj
Copy link
Member

pcj commented Dec 2, 2019

Often the cause of protobuf library rebuilding is environment variables changing, typically PATH. This can occur if you open a new terminal, for example. Newer versions of bazel are more resistant to this.

@sudoforge
Copy link
Contributor

sudoforge commented Dec 3, 2019

I have this issue and most definitely don't have any variance in my environment variables. I'm also using Bazel v1.2.1.

Adding my comment from another issue:

Yeah, I have to agree that it's pretty annoying to have to wait for all 220+ protoc targets to build whenever the "sandbox goes stale" (I don't have metrics on this, but it seems to be every 5-10 minutes); I've never seen this message except when running //:buildifier just to format my Starlark files.

I want to be idiomatic and use Bazel to build buildifier, but I have to agree with @nrvnrvn; it seems much more reasonable to grab a binary (via go get or http_file()) than to wait the couple minutes (yes, minutes) every time I want to format.

Consider this; where bazel run //:buildifier is set up to execute in a pre-commit hook if WORKSPACE, BUILD, or BUILD.bazel files are detected:

➜ git commit
Formatting Bazel files...
INFO: Analyzed target //:buildifier (27 packages loaded, 595 targets configured).
INFO: Found 1 target...
Target //:buildifier up-to-date:
  bazel-bin/buildifier.bash
INFO: Elapsed time: 76.502s, Critical Path: 21.27s
INFO: 195 processes: 195 linux-sandbox.
INFO: Build completed successfully, 200 total actions
INFO: Build completed successfully, 200 total actions
[master 78c4c39] initial commit
...

@jathu
Copy link

jathu commented Dec 5, 2019

Does setting --incompatible_strict_action_env fix this issue? A solution from this thread: bazelbuild/bazel#7095

Edit: it seems to work when this is set in bazelrc

@mariusgrigoriu
Copy link

Since it appears that you're running buildifier as a githook, know that the PATH is different in your githook script, so you'd need to manage your action_env appropriately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants