bazel lock file updating

[maliberty]

@hzeller @QuantamHD @oharboe

Updating the bazel lock file is annoyingly serial. Claude suggests either

1. Don't commit the lockfile (simplest)
   Add MODULE.bazel.lock to .gitignore and let each developer (and CI) regenerate it locally. This is what many Bazel projects do. The tradeoff is you lose hermetic reproducibility of the dependency resolution step — but in practice, if your MODULE.bazel pins versions tightly (which it should), the lockfile doesn't add much safety. You can run bazel mod deps --lockfile_mode=update in CI to regenerate it.

2. Regenerate it in CI via a merge bot
   Keep the lockfile committed but don't let humans touch it. Set up automation (GitHub Action, post-merge hook) that runs bazel mod deps --lockfile_mode=update, commits the result, and pushes. PRs that touch MODULE.bazel trigger the regen; PRs that don't, don't touch the lockfile at all. This eliminates serialization since only one bot writes to the file.

What is the Google best practice in this area?

[hzeller]

Bazel recommendations is to put it in version control https://bazel.build/versions/7.2.0/external/lockfile#best-practices
The XLS team does it that way.

Personally I think it is silly, and my personal projects don't do that: I don't check in the *.lock file and I have it in the .gitignore.

Given that the BCR never allows to change existing projects but modifications are new *.bcr.$N versions, I can't really think of a situation in which the dependencies are secretly changing. So there is absolutely no benefit that I can see, just the pain of updating this thing for no good reason...

[maliberty]

I would rather ignore it as well. @QuantamHD or @mikesinouye opinion?

[maliberty]

fwiw I asked claude if the OR dependencies are tightly pinned:

  Bottom line: Direct deps are well-pinned, so day-to-day reproducibility risk  
  is low. But the lock file provides real value for transitive dep pinning,
  supply-chain integrity, and extension determinism. Dropping it would be fine  
  for casual development but weakens guarantees for reproducible builds and
  security auditability. I'd keep it tracked.

[QuantamHD]

I'd be in favor of a CI based solution

[maliberty]

@oharboe do you have such an action OR could copy?

[oharboe]

@nekronos could you help @maliberty with any questions he has in regards to how to set up post-merge linting, formatting, bazelisk mod tidy, module lock, etc. all the stuff we are automating post-merge after we switched to merge queues...

Thanks!