Bazel build files are now maintained primarily with `bazel run
gazelle`. This will analyze and merge changes into the build files as
necessitated by certain code changes (e.g. the introduction of new
modules).
In some cases there hints to gazelle in the build files, such as `#
gazelle:erlang...` or `# keep` comments. xref checks on plugins that
depend on the cli are a good example.
* Add gazelle for use with update-repos command
* Use explicit BUILD.app_name files for erlang app deps
This allows us to remove the duplicate definitions in
workspace_helpers.bzl
These files are generated with gazelle. For instance:
BUILD.ra is generated with `bazel run gazelle -- update-repos
--verbose --build_files_dir=bazel hex.pm/ra@2.4.6`
Running gazelle this way will modify the WORKSPACE file, as gazelle
does not yet support MODULE.bazel files. Such changes to the WORKSPACE
can be dropped, and should not be committed. It may also update the
`moduleindex.yaml` file. Changes to `moduleindex.yaml` should be
committed.
However
* skip the explicit bazel/BUILD.osiris file, as osiris already contains the file in its repo
* skip the explict BUILD.inet_tcp_proxy_dist file, since the repo already contains a bazel BUILD.bazel file
gazelle command: `bazel run gazelle -- update-repos --verbose --build_files_dir=bazel
inet_tcp_proxy_dist=github.com/rabbitmq/inet_tcp_proxy@master`
* jose is imported with `bazel run gazelle -- update-repos --verbose --build_files_dir=bazel
jose=github.com/michaelklishin/erlang-jose@d63c1c5c8f9c1a4f1438e234b886de8607a0034e`
* Move the bats dep directly to WORKSPACE, drop workspace_helpers.bzl
* Use bzlmod in windows tests
Rin Kuryloski