commit | dd7b2d22fb0e13547505bacd862b92bf56a35983 | [log] [tgz] |
---|---|---|
author | Serge Bazanski <serge@nexantic.com> | Fri Jul 02 17:13:22 2021 +0200 |
committer | Sergiusz Bazanski <serge@nexantic.com> | Fri Jul 02 16:28:59 2021 +0000 |
tree | ef18d20d2688a62bdf80147ec343e05789ac6cae | |
parent | 76003f807b24a22476b14bc308939fc62e1ad6a2 [diff] |
third_party/go: add package missing from dependency graph This is a Windows-specific package being pulled in by github.com/spf13/cobra. We don't need it, and we don't ever build it (it's behind a select() gate depending on the Windows platform), but its lack causes us to not be able to perform Bazel queries against anything that stumbles upon this select statement. Notably, things like ibazel don't work without the ability to query dependencies of a target. In theory, cquery could be used of query (and cquery would know that it's not running on a windows platform and not attempt to resolve the missing package). This might happen some day, but: 1) cquery currently does not support the buildfiles() function, which is needed by tools like ibazel to find not only source/data/target dependencies for a taret, but also every BUILD/.bzl file that influenced that target. See: https://github.com/bazelbuild/bazel-watcher/issues/305#issuecomment-627312885 2) It's generally good practice to not have missing objects in our dependency graph, I think. We will sooner or later start using this data in CI and other automation, and it might be useful to make an assumption, at some point, that we don't ever have a broken target dependency graph. Testing plan: the following now works: bazel query 'deps(set(//...))' --output=xml Change-Id: Ic45e293b868b0aaa707f31384b4b24626ba23e29 Reviewed-on: https://review.monogon.dev/c/monogon/+/200 Reviewed-by: Leopold Schabel <leo@nexantic.com>
This is the main repository containing the source code for the Monogon Project.
⚠️ This is pre-release software that happens to be publicly available. Nothing to see here, please move along.
Our build environment requires a working Podman binary (your distribution should have one).
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)
This repository is compatible with the IntelliJ Bazel plugin, which enables full autocompletion for external dependencies and generated code. All commands run inside the container, and necessary paths are mapped into the container.
The following steps are necessary:
Install Google's Bazel plugin in IntelliJ. On IntelliJ 2020.3 or later, you need to install a beta release of the plugin.
Add the absolute path to your ~/.cache/bazel-monogon
folder to your idea64.vmoptions
(Help → Edit Custom VM Options) and restart IntelliJ:
-Dbazel.bep.path=/home/leopold/.cache/bazel-monogon
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.
Use File → Import Bazel project... to create a new project from .bazelproject
.
After running the first sync, everything should now resolve in the IDE, including generated code.
Launch the node:
scripts/bin/bazel run //:launch
Run a kubectl command:
scripts/bin/bazel run //metropolis/cli/dbg -- kubectl describe
Run tests:
scripts/bin/bazel test //...