search

bazelbuild / bazel

a fast, scalable, multi-language and extensible build system
https://bazel.build
Apache License 2.0
22.74k stars 3.99k forks source link

Repository rules get reevaluated too often, starting from 7.1.0 #22494

Open blorente opened 1 month ago

blorente commented 1 month ago

Description of the bug:

Starting from Bazel 7.1.0, repository rules that used to be cached and not re-run have started being re-run. This might be a case of Hyrum's Law, but we did rely on this behaviour for caching xcode resolutions internally.

Which category does this issue belong to?

Rules API

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

➜ USE_BAZEL_VERSION='7.0.2' bazel fetch @counter//... INFO: All external dependencies fetched successfully.

- Run it with Bazel 7.1.0. The repository rule got re-evaluated:

➜ USE_BAZEL_VERSION='7.1.0' bazel fetch @counter//... Starting local Bazel server and connecting to it... INFO: Invocation ID: f7704521-eeda-44e8-b609-4c51d37851be DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:5:10: Running counter DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:12:10: Writing counter value 24 ...

➜ USE_BAZEL_VERSION='7.1.0' bazel fetch @counter//... INFO: Invocation ID: 62d9655c-ff33-4d49-9f22-a7a255d42136 DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:5:10: Running counter DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:12:10: Writing counter value 25 ...

- The same thing happens on the latest bazel:

➜ USE_BAZEL_VERSION='latest' bazel fetch @counter//... Starting local Bazel server and connecting to it... DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:5:10: Running counter DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:12:10: Writing counter value 26 INFO: All external dependencies for these targets fetched successfully.

➜ USE_BAZEL_VERSION='latest' bazel fetch @counter//... DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:5:10: Running counter DEBUG: /Volumes/code/scratch/scratch/repo-rules/rules.bzl:12:10: Writing counter value 27 INFO: All external dependencies for these targets fetched successfully.



### Which operating system are you running Bazel on?

macOS

### What is the output of `bazel info release`?

Release numbers are in the repro, but this reproduces on `latest`

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

_No response_

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

_No response_

### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

_No response_

### Have you found anything relevant by searching the web?

I haven't found anything searching through GH issues, and the documentation on repository rules seems to indicate that setting `local = True` and `configure = True` should prevent the rule from running. 

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

_No response_
fmeum commented 1 month ago

ctx.read now watches the contents of files it reads, which is usually what you want.

In this case you clearly don't, so you should be able to get the old behavior back by setting watch = "no" on the read call.

blorente commented 1 month ago

Thanks @fmeum for the quick response! If that is the case, I might be misreading the documentation on repository rule evaluation. I think this is the relevant passage:

The content of any file passed to the read(), execute() and similar methods of repository_ctx which is referred to by a label (for example, //mypkg:label.txt but not mypkg/label.txt)

In this case, the repository rule refers to it by a path (link), so I would have expected the rule to not get invalidated. Am I misinterpreting the documentation?

fmeum commented 1 month ago

You aren't, the docs are wrong here (they weren't updated with the change).

Cc @Wyverald