What version of gazelle are you using?
0.24.0
What version of rules_go are you using?
0.30.0
What version of Bazel are you using?
5.0.0
Does this issue reproduce with the latest releases of all the above?
Yes
What operating system and processor architecture are you using?
Linux/x64
What did you do?
Clean rebuild of a large project.
What did you expect to see?
No messages about restarting fetches. Or at least none that last long enough to be visible.
What did you see instead?
Messages like
Fetching @com_github_aws_aws_sdk_go; Restarting.
From my own experience writing repository rules, there's a little bit of a gotcha which is that calls to ctx.path() on a label referencing files in a repository which hasn't been fetched yet will result in restarting execution of your rule, as documented though not super clearly and not really emphasized.
In particular, lines like
https://github.com/bazelbuild/bazel-gazelle/blob/4d2e96a20ad1a32b48bd2dc5c44d0627d34063bf/internal/go_repository.bzl#L150
or
https://github.com/bazelbuild/bazel-gazelle/blob/4d2e96a20ad1a32b48bd2dc5c44d0627d34063bf/internal/go_repository.bzl#L194
will result in a restart, because as the docs say
To avoid unnecessary restarts (which are expensive, as network access might have to be repeated), label arguments are prefetched, provided all label arguments can be resolved to an existing file. Note that resolving a path from a string or a label that was constructed only during execution of the function might still cause a restart.
That's not great, because that means re-running the fetch from https://github.com/bazelbuild/bazel-gazelle/blob/4d2e96a20ad1a32b48bd2dc5c44d0627d34063bf/internal/go_repository.bzl#L102 (or from other code paths).
Possible workarounds for this are to pre-fetch the result of ctx.path() at the beginning of the rule implementation function, before anything more expensive has happened, and/or for static strings add them as private attributes to the rule so that bazel can know to fetch them prior to beginning execution of the rule.
What version of gazelle are you using?
0.24.0
What version of rules_go are you using?
0.30.0
What version of Bazel are you using?
5.0.0
Does this issue reproduce with the latest releases of all the above?
Yes
What operating system and processor architecture are you using?
Linux/x64
What did you do?
Clean rebuild of a large project.
What did you expect to see?
No messages about restarting fetches. Or at least none that last long enough to be visible.
What did you see instead?
Messages like
From my own experience writing repository rules, there's a little bit of a gotcha which is that calls to
ctx.path()on a label referencing files in a repository which hasn't been fetched yet will result in restarting execution of your rule, as documented though not super clearly and not really emphasized.In particular, lines like
https://github.com/bazelbuild/bazel-gazelle/blob/4d2e96a20ad1a32b48bd2dc5c44d0627d34063bf/internal/go_repository.bzl#L150
or
https://github.com/bazelbuild/bazel-gazelle/blob/4d2e96a20ad1a32b48bd2dc5c44d0627d34063bf/internal/go_repository.bzl#L194
will result in a restart, because as the docs say
That's not great, because that means re-running the fetch from https://github.com/bazelbuild/bazel-gazelle/blob/4d2e96a20ad1a32b48bd2dc5c44d0627d34063bf/internal/go_repository.bzl#L102 (or from other code paths).
Possible workarounds for this are to pre-fetch the result of
ctx.path()at the beginning of the rule implementation function, before anything more expensive has happened, and/or for static strings add them as private attributes to the rule so that bazel can know to fetch them prior to beginning execution of the rule.