grpc
Do not persist MODULE.bazel.lock
MODULE.bazel.lock is platform dependent so it’s better not to persist it
Signed-off-by: Matthieu MOREL [email protected]
Another thing, to publish to BCR, there is a bit of configuration, see https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md and also an App, see https://github.com/apps/publish-to-bcr
@veblush, could you review?
@mmorel-35, we have never done releases of this repo, so there will be things to figure out
It seems like it is better to persist it, see https://bazel.build/external/lockfile#best-practices
Use bazelisk to run Bazel, and include a .bazelversion file in version control that specifies the Bazel version corresponding to the lockfile.
Yeah, we're not doing that. So I think we need to delete the lock file.
Since this project needs to run with multiple different Bazel versions, it'd also be important to know whether the lock file detects it was used by a different Bazel version.
I also wonder if the lock file could be used for a supply-chain attack; if Bazel trusts the lock file and ignores the files we review, someone could generate a real lock file but then modify it in subtle ways. The file is too large for such a thing to be noticed on human review. That would definitely have been possible for maven_install; I don't know for bzlmod though.
That would definitely have been possible for maven_install; I don't know for bzlmod though.
This could be detected by a CI, since it seems the output is expected to be stable (generating it twice generates the same bytes).
LGTM. I'd like to note that bazel.lock file is contained within this repo and shouldn't affect the downstream.
