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

--repo_env causes fetch/query thrashing #11943

Closed
laurentlb opened this issue Aug 13, 2020 · 9 comments
Closed

--repo_env causes fetch/query thrashing #11943

laurentlb opened this issue Aug 13, 2020 · 9 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug

Comments

@laurentlb
Copy link
Contributor

@laurentlb it is the bazel build --repo_env that causes the fetch/query thrashing. Both bazel query and bazel fetch do not have a --repo_env flag, but its presence in bazel build causes bazel to consider the fetch and build steps to be different, hence the thrashing.

Originally posted by @TheButlah in #10961 (comment)

@TheButlah
Copy link

TheButlah commented Aug 13, 2020

For some additional context on why this is important in my particular use case - we rely on bazel query for several scripts/systems to interoperate with bazel, so it gets invoked about as frequently as bazel build. We also have set the default C/C++ compiler via a build --repo_env=CXX=clang++-11 --repo_env=CC=clang-11 in our .bazelrc file. This means that we get consistent re-fetching of external workspaces. Suffice to say, its generating quite a bit of tooling pain for our team.

Note that this seems to occur in at least 3.2.0 and 3.4.1

@laurentlb
Copy link
Contributor Author

If --repo_env forces a re-evaluation, the flag should be available for bazel query too.

@gregestren gregestren added team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug untriaged labels Aug 17, 2020
@philwo philwo added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels Nov 25, 2020
@TheButlah
Copy link

Any movement here?

@liuliu
Copy link
Contributor

liuliu commented Jan 20, 2021

One way I worked around this is to have a dedicated output_base when running bazel query. It seems to be the solution done by the VSCode Bazel plugin as well.

@pcjanzen
Copy link
Contributor

A no-good, very bad thing that you absolutely should not do under any circumstances because it is undocumented and unsupported and could stop working at any moment is to put

common --client_env=FOO=BAR

into your .bazelrc.

@bjacklyn
Copy link

@chancila -- I believe your repo_env change may also fix this issue
c2bdd03

@chancila
Copy link
Contributor

yea I think there's a bunch of duplicate issues around this #12689

@fmeum
Copy link
Collaborator

fmeum commented Dec 12, 2022

@sgowroji Can be closed based on #11943 (comment).

@sgowroji
Copy link
Member

We are closing this issue w.r.t the above #11943 (comment). Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug
Projects
None yet
Development

No branches or pull requests

10 participants