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

Repository rule restart behavior depends on attribute names #13441

Open
getim opened this issue May 7, 2021 · 1 comment
Open

Repository rule restart behavior depends on attribute names #13441

getim opened this issue May 7, 2021 · 1 comment
Assignees
Labels
P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug

Comments

@getim
Copy link

getim commented May 7, 2021

Description of the problem / feature request:

As the documentation clearly states, repository rules will be restarted whenever the content of any file used and referred to by a label changes. If a repository rule depends on a filegroup for example and the contents of a file in that filegroup changes, the rule will not be restarted.

However, the logic that finds all files referred to directly by attributes stops on the first label-attribute that doesn't resolve to an existing files. On top of that, the order in which the attributes are checked seems to depend on the names of those attributes. That means that a repository rule depending on both a direct file and a filegroup can have the direct file as a restarting dependency or not, depending on the names of the attributes.

The restarting behavior can also be confirmed in the @<external_name>.marker files in the output base, where it only in some cases lists the direct file on a FILE:-line.

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

Make repository rule restarting behavior well defined and more predictable.

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

Small example with a repository downloading a file with a dependency on two empty local files foo and bar:

# WORKSPACE
load("my_http_download.bzl", "my_http_download")

my_http_download(
    name = "example",
    foo = "//:foo",
    bar = "//:bar",
)   
# my_http_download.bzl
def _my_http_download(ctx):
    ctx.download(
        url = "https://example.com",
        output = "index.html",
    )
    ctx.file("WORKSPACE")
    ctx.file("BUILD", content="exports_files(['index.html'])")

my_http_download = repository_rule(
    implementation = _my_http_download,
    attrs = {
        "foo": attr.label(),
        "bar": attr.label(),
    }
)
# BUILD
filegroup(
    name = "foo_filegroup",
    srcs = ["foo"],
    visibility = ["//visibility:public"],
)   

filegroup(
    name = "bar_filegroup",
    srcs = ["bar"],
    visibility = ["//visibility:public"],
)   

and bazel build @example//:index.html

  • Changing the dependency on //:foo into //:foo_filegroup makes the rule only restart when bar changes (as expected).
  • Changing the dependency on //:bar into //:bar_filegroup (but keeping the dependency on //:foo) makes the rule NOT restart when foo changes.

If the name of the foo attribute changes to afoo the incorrect behavior is the other way around:

  • Changing the dependency on //:bar into //:bar_filegroup makes the rule only restart when foo changes (as expected).
  • Changing the dependency on //:foo into //:foo_filegroup (but keeping the dependency on //:bar) makes the rule NOT restart when bar changes.

What operating system are you running Bazel on?

Arch Linux, same behavior observed on CentOS 7.

What's the output of bazel info release?

release 4.0.0

Have you found anything relevant by searching the web?

The checking on direct files seems to happen here: https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/repository/starlark/StarlarkRepositoryFunction.java#L189

As the EvalException is caught outside the loop, the other attributes are not checked anymore after throwing.

@lberki lberki added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. untriaged labels May 7, 2021
@sventiffe sventiffe added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label May 7, 2021
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
@meteorcloudy meteorcloudy added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels Feb 22, 2022
@fmeum
Copy link
Collaborator

fmeum commented May 5, 2023

@Wyverald Just noticed that this could also be relevant to your proposal.

fmeum added a commit to fmeum/bazel-gazelle that referenced this issue May 9, 2023
The list of `go_repository_tools_srcs` contained an invalid Label, which
silently broke change detection for bootstrap Gazelle due to
bazelbuild/bazel#13441.
fmeum added a commit to fmeum/bazel that referenced this issue May 9, 2023
Even with this commit, the fact that a particular label in a repository
rule's label attributes does not resolve to a regular file is not
tracked, which means that there is still a potential for incorrect
incremental fetches.

Work towards bazelbuild#13441
fmeum added a commit to fmeum/bazel that referenced this issue May 9, 2023
Even with this commit, the fact that a particular label in a repository
rule's label attributes does not resolve to a regular file is not
tracked, which means that there is still a potential for incorrect
incremental fetches.

Work towards bazelbuild#13441
fmeum added a commit to fmeum/bazel that referenced this issue May 9, 2023
Even with this commit, the fact that a particular label in a repository
rule's label attributes does not resolve to a regular file is not
tracked, which means that there is still a potential for incorrect
incremental fetches.

Work towards bazelbuild#13441
fmeum added a commit to fmeum/bazel that referenced this issue May 9, 2023
Even with this commit, the fact that a particular label in a repository
rule's label attributes does not resolve to a regular file is not
tracked, which means that there is still a potential for incorrect
incremental fetches.

Work towards bazelbuild#13441
fmeum added a commit to fmeum/bazel that referenced this issue May 9, 2023
Even with this commit, the fact that a particular label in a repository
rule's label attributes does not resolve to a regular file is not
tracked, which means that there is still a potential for incorrect
incremental fetches.

Work towards bazelbuild#13441
linzhp pushed a commit to bazel-contrib/bazel-gazelle that referenced this issue May 9, 2023
The list of `go_repository_tools_srcs` contained an invalid Label, which
silently broke change detection for bootstrap Gazelle due to
bazelbuild/bazel#13441.
fmeum added a commit to fmeum/bazel that referenced this issue May 10, 2023
Even with this commit, the fact that a particular label in a repository
rule's label attributes does not resolve to a regular file is not
tracked, which means that there is still a potential for incorrect
incremental fetches.

Work towards bazelbuild#13441
copybara-service bot pushed a commit that referenced this issue May 11, 2023
Even with this commit, the fact that a particular label in a repository rule's label attributes does not resolve to a regular file is not tracked, which means that there is still a potential for incorrect incremental fetches.

Work towards #13441

Closes #18352.

PiperOrigin-RevId: 531150549
Change-Id: I086e4813ca88a3f49cde77d9be20adaaf954834b
iancha1992 pushed a commit to iancha1992/bazel that referenced this issue May 15, 2023
Even with this commit, the fact that a particular label in a repository rule's label attributes does not resolve to a regular file is not tracked, which means that there is still a potential for incorrect incremental fetches.

Work towards bazelbuild#13441

Closes bazelbuild#18352.

PiperOrigin-RevId: 531150549
Change-Id: I086e4813ca88a3f49cde77d9be20adaaf954834b
fweikert pushed a commit to fweikert/bazel that referenced this issue May 25, 2023
Even with this commit, the fact that a particular label in a repository rule's label attributes does not resolve to a regular file is not tracked, which means that there is still a potential for incorrect incremental fetches.

Work towards bazelbuild#13441

Closes bazelbuild#18352.

PiperOrigin-RevId: 531150549
Change-Id: I086e4813ca88a3f49cde77d9be20adaaf954834b
iancha1992 added a commit that referenced this issue Jun 6, 2023
…8412)

Even with this commit, the fact that a particular label in a repository rule's label attributes does not resolve to a regular file is not tracked, which means that there is still a potential for incorrect incremental fetches.

Work towards #13441

Closes #18352.

PiperOrigin-RevId: 531150549
Change-Id: I086e4813ca88a3f49cde77d9be20adaaf954834b

Co-authored-by: Fabian Meumertzheim <[email protected]>
Co-authored-by: keertk <[email protected]>
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-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug
Projects
None yet
Development

No branches or pull requests

8 participants