bazel query cache problem with flag incompatible_allow_tags_propagation

[ouchuji]

ATTENTION! Please read and follow:

• if this is a question about how to build / test / query / deploy using Bazel, or a discussion starter, send it to bazel-discuss@googlegroups.com
• if this is a bug or feature request, fill the form below as best as you can.

Description of the problem / feature request:

bazel query would not use the external repository cahche when we use the incompatible_allow_tags_propagation flag at the .bazelrc.

• Not add incompatible_allow_tags_propagation at .bazelrc.

The build time is short when we had already built a target, bazel build and bazel query all used cached exteranl repos placed at workspace, very perfect.

• Add incompatible_allow_tags_propagation at .bazelrc.

Use bazel query after bazel build time is very long, and bazel would download external repos again, it is terrible.

Use bazel build after bazel query, bazel would download external repos again,

As you can see, add incompatible_allow_tags_propagation flag seems not incompatioble with bael 3.0, but we we need this flag for tags progapation.

• More serious proble when incompatible_allow_tags_propagation at .bazelrc.

When we edit a BUILD file, the bazel would query automaticaly at the backend, and the the bazel query would download all external repo again, it is a long time to wait. We almost can not work normally.

Feature requests: what underlying problem are you trying to solve with this feature?

When we add incompatible_allow_tags_propagation at the .bazelrc, bazel query would use the repository cache, but not download them again from the network. And when we edit a build file, the backend bazel query process not hang on a long time.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Remove the flag incompatible_allow_tags_propagation from .bzelrc.

What operating system are you running Bazel on?

Ubutu 18.04 LTS

What's the output of bazel info release?

release 3.0.0.

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

No.

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

git@github.com:bazelbuild/rules_nodejs.git ; 34ae5469b654b9e36bca0c4a5ba97a28955fc654 ; bd83907954d1b3cd53dff01c37e3c4964890ef5c

Have you found anything relevant by searching the web?

I find this problem is start at release version 2.2, and this version seems has some change for cquery https://blog.bazel.build/2020/03/03/bazel-2-2.html#cquery.

Places to look:

• StackOverflow: http://stackoverflow.com/questions/tagged/bazel
• GitHub issues: https://github.com/bazelbuild/bazel/issues
• email threads on https://groups.google.com/forum/#!forum/bazel-discuss

Any other information, logs, or outputs that you want to share?

I test this via repo rules_nodejs (https://github.com/bazelbuild/rules_nodejs) tag 1.6, we can easily reproduce this problem via the steps above.

If the files are large, upload as attachment or provide link.

[aiuto]

I'm not sure who has the most knowledge of this, so letting two teams see it.
It was added here. #8829
Based on this: #7766

cc/ @juliexxia It looks like ExecutionGroups might replace the needs from the design.

[benjaminp]

This is a consequence of a3a2215. Life typically improves if Starlark semantic options are placed in the .bazelrc common section rather than, e.g., build.

[keith]

Related: #10961

[ouchuji]

@keith Thank you for your mention, the common --incompatible_allow_tags_propagation solved this problem.

[katre]

Closing this since it seems to be solved. Any further questions can be on #10961.