Teach Gazelle about k8s import paths in @kubernetes

This prevents "gazelle update" from attempting to add its
go_repository equivalent to the auto-generated BUILD file.

We still need to keep the entries in Go.mod and Gazelle
will generate unused go_repository rules for them, because
`go mod tidy` would break otherwise (and we cannot use a
replace directive or a symlink, because replacing requires
a Go.mod file, which the Kubernetes repo does not have,
and symlinks are not a thing for external dependencies).

This was broken in master since D271.

Test Plan:
Ran `scripts/gazelle.sh`, `bazel build :gopath`,
and then the script again. This previously broke and now works.

X-Origin-Diff: phab/D310
GitOrigin-RevId: 79c1b2836e86df6baddbc1a1dd770e6c0dd84133
2 files changed
tree: e81cc19c682a21084ec5ab700e61fe4396c81f8d
  1. build/
  2. core/
  3. scripts/
  4. .bazelignore
  5. .bazelrc
  6. BUILD
  7. nogo_config.json
  8. README.md
  9. WORKSPACE
README.md

Nexantic monorepo

This is the monorepo storing all of nexantic's internal projects and libraries.

Environment

We assume a Fedora host system provisioned using rW, and IntelliJ as the IDE.

For better reproducibility, all builds are executed in containers.

Usage

Spinning up: scripts/create_container.sh

Spinning down: scripts/destroy_container.sh

Running commands: scripts/run_in_container.sh <...>

Using bazel using a wrapper script: scripts/bin/bazel <...> (add to your local $PATH for convenience)

Creating local symlinks for generated Go code

Unfortunately, the Go tooling does not yet know about Bazel, so we need to copy generated code to the source tree such that native Go modules work.

This creates a fake GOPATH and symlinks for generated packages:

scripts/symlink_generated_files.sh
bazel build :gopath

Any top-level Go targets that use generated code have to be dependencies of the :gopath target.

See https://phab.monogon.dev/D305 for details.

IntelliJ

This repository is compatible with the IntelliJ Bazel plugin. All commands run inside the container, and necessary paths are mapped into the container.

We check the entire .ijwb project directory into the repository, which requires everyone to use the latest version of both IntelliJ and the Bazel plugin, but eliminates manual setup steps.

The following steps are necessary:

  • Install Google's official Bazel plugin in IntelliJ.

  • Add the absolute path to your ~/.cache/bazel-nxt folder to your idea64.vmoptions (Help → Edit Custom VM Options) and restart IntelliJ:

    -Dbazel.bep.path=/home/leopold/.cache/bazel-nxt

  • Set "Bazel Binary Location" in Other Settings → Bazel Settings to the absolute path of scripts/bin/bazel. This is a wrapper that will execute Bazel inside the container.

  • Open the .ijwb folder as IntelliJ project.

  • Disable Vgo support for the project.

  • Run a non-incremental sync in IntelliJ

The plugin will automatically resolve paths for generated files.

If you do not use IntelliJ, you need to use the scripts/bazel_copy_generated_for_ide.sh script to copy files locally.