Add a git merge driver for `MODULE.bazel.lock`

Adds a `jq` script to `scripts/` that merges any number of `MODULE.bazel.lock` files without using Bazel or reading the corresponding `MODULE.bazel` files.

The lockfile docs now have a section explaining the steps needed to set up this script as a custom merger driver for Git, which means that merge conflicts in `MODULE.bazel.lock` files will always be resolved automatically. Note that resolution may emit lockfiles with redundant information that will be dropped by subsequent Bazel invocations.

When Bazel encounters an error during lockfile parsing that could be caused by a merge conflict, it emits a different error message with a link to the docs. This required fixing the following kind of server crash when a conflict marker occurs inside a `recordedFileInputs` object:
```
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node 'com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue$$Lambda/0x000000f8011da998@314cd9ee' (requested by nodes 'RegistryKey{url=https://bcr.bazel.build/}')
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:557)
	at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:426)
	at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1403)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
Caused by: java.lang.IllegalArgumentException: the provided path should be absolute in the filesystem
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:143)
	at com.google.devtools.build.lib.rules.repository.RepoRecordedInput$RepoCacheFriendlyPath.createOutsideWorkspace(RepoRecordedInput.java:202)
	at com.google.devtools.build.lib.rules.repository.RepoRecordedInput$RepoCacheFriendlyPath.parse(RepoRecordedInput.java:222)
	at com.google.devtools.build.lib.rules.repository.RepoRecordedInput$File$1.parse(RepoRecordedInput.java:265)
	at com.google.devtools.build.lib.bazel.bzlmod.GsonTypeAdapterUtil$11.read(GsonTypeAdapterUtil.java:376)
	at com.google.devtools.build.lib.bazel.bzlmod.GsonTypeAdapterUtil$11.read(GsonTypeAdapterUtil.java:367)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:186)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
	at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
	at com.google.devtools.build.lib.bazel.bzlmod.LockFileModuleExtension_GsonTypeAdapter.read(LockFileModuleExtension_GsonTypeAdapter.java:171)
	at com.google.devtools.build.lib.bazel.bzlmod.LockFileModuleExtension_GsonTypeAdapter.read(LockFileModuleExtension_GsonTypeAdapter.java:17)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
	at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
	at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue_GsonTypeAdapter.read(BazelLockFileValue_GsonTypeAdapter.java:129)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue_GsonTypeAdapter.read(BazelLockFileValue_GsonTypeAdapter.java:15)
	at com.google.gson.Gson.fromJson(Gson.java:991)
	at com.google.gson.Gson.fromJson(Gson.java:956)
	at com.google.gson.Gson.fromJson(Gson.java:905)
	at com.google.gson.Gson.fromJson(Gson.java:876)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileFunction.getLockfileValue(BazelLockFileFunction.java:93)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileFunction.compute(BazelLockFileFunction.java:73)
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:468)
	... 7 more
```

Alternatives considered:
* Letting Bazel resolve the conflict would require building knowledge about particular version control systems and their conflict style into Bazel. It would also either require the user to resolve conflicts in `MODULE.bazel` first or deviate from the current behavior that the lockfile is not updated when any Bzlmod error is encountered. The jq script can be used as is by every VCS with merge driver support and resolves the conflict in `MODULE.bazel.lock` independently of `MODULE.bazel`.
* Implementing the git merge driver as a `bazel mod` subcommand. This could be the source of intransparent slowdowns during regular git operations, which may even be triggered by other tools such as IDEs. The jq script is very fast.
* Implementing the merger as a Go binary in buildtools would replace the ubiquitous jq tool with a special purpose binary while also not solving the problem that per-user action is required once to register a custom merge driver.

Implements https://docs.google.com/document/d/1TjA7-M5njkI1F38IC0pm305S9EOmxcUwaCIvaSmansg/edit#heading=h.5mcn15i0e1ch

RELNOTES: Git merge conflicts in `MODULE.bazel.lock` files can be resolved automatically. See https://bazel.build/external/lockfile#automatic-resolution for the required setup.

Closes #22428.

PiperOrigin-RevId: 640596606
Change-Id: I20659e3e53a7d8f2529f2ad5a3e7f258d7af026d
8 files changed
tree: 05e12668e286893baaebbc9d713c08667259b981
  1. .bazelci/
  2. .github/
  3. examples/
  4. scripts/
  5. site/
  6. src/
  7. third_party/
  8. tools/
  9. .bazelrc
  10. .bazelversion
  11. .gitattributes
  12. .gitignore
  13. AUTHORS
  14. bazel_downloader.cfg
  15. BUILD
  16. CHANGELOG.md
  17. CODE_OF_CONDUCT.md
  18. CODEOWNERS
  19. combine_distfiles.py
  20. combine_distfiles_to_tar.sh
  21. compile.sh
  22. CONTRIBUTING.md
  23. CONTRIBUTORS
  24. distdir.bzl
  25. extensions.bzl
  26. LICENSE
  27. maven_install.json
  28. MODULE.bazel
  29. MODULE.bazel.lock
  30. rbe_extension.bzl
  31. README.md
  32. repositories.bzl
  33. requirements.txt
  34. SECURITY.md
  35. WORKSPACE
  36. WORKSPACE.bzlmod
  37. workspace_deps.bzl
README.md

Bazel

{Fast, Correct} - Choose two

Build and test software of any size, quickly and reliably.

  • Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.

  • One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.

  • Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.

  • Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.

Getting Started

Documentation

Reporting a Vulnerability

To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.

Contributing to Bazel

See CONTRIBUTING.md

Build status