| commit | f12bedfa4cd144c3abc4deac58405067d55f9c87 | [log] [tgz] |
|---|---|---|
| author | Serge Bazanski <serge@nexantic.com> | Fri Jan 15 16:58:50 2021 +0100 |
| committer | Serge Bazanski <serge@nexantic.com> | Fri Jan 15 16:58:50 2021 +0100 |
| tree | ddbc408e424a0ea8e446bcf0022ee16278202d63 | |
| parent | c3ad846e0eaf4cf008130a643ff247aa27531e17 [diff] |
*: bump up Go dependencies This started off as 'let's bump gVisor'. However, pulling that thread resulted in quite a few things that also required bumping for the build to actually work. Here I come back from a day in the Bazel mines, bearing fruits of my labor. Notable changes: - bump up gVisor - bump up containerd - bump up Bazel - bump up rules_go, rules_docker, Gazelle - use google.golang.org/protobuf (the 'new' go proto package) - bump up gRPC (but not too much, as go-etcd is still straggling) Notable effects: - new gVisor supports TTY allocation (kubectl run -it --image=ubuntu:20.04 ubuntu bash now works!) Notable notes: - gVisor shim has new been rolled into the main gVisor package and is slightly easier to build (we can get rid of a bunch of patches). - Opencontainers' runtime-specs now follow containerd instead of gVisor - gVisor had to be taught to use the slightly newer runtime-specs via a new patch. - go_rule() in Starlark is now deprecated, and we had to change our Starlark rule definitions to use rule() instead. We also had to patch gVisor to do that (as there hasn't yet been a release that rolled this up). - Gazelle now supports different naming schemes for generated Go targets - either the old //foo/bar:go_default_library scheme, or a new and nicer //foo/bar:bar scheme. We currently force the usage of the old scheme, as switching over is probably not going to be easy (we use a lot of external Bazel files, and we have to wait for their compatibility with the new scheme first). - New Bazel/rules_go sets a TMPDIR long enough to generate paths (via ioutil.TempDir) to which sockets cannot be bound (108-byte limit). - The new protobuf API is incompatible with gogoproto. containerd/ttrpc uses gogoproto, but we are smart enough to pull in the old protobuf library as gogoproto's transitive dep. However, ttrpc also wants to use some proto-generated grpc bits, and that doesn't work. We have to pull in a ttrpc fork from a PR that hasn't yet been merged that fixes this issue. Test Plan: Refactor only, should be covered by tests. X-Origin-Diff: phab/D689 GitOrigin-RevId: 1188c0605d25e7f40307fab5fd96e7019f3a9171
This is the main repository containing Monogon's public source code, including Metropolis.
We assume a Fedora host system provisioned using rW, and IntelliJ as the IDE.
For better reproducibility, all builds are executed in containers.
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. 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.
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.
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.
It's strongly recommend to use our project presets for file watchers and other IDE features. Run this command and re-open the project in order to install them:
bazel run intellij/localconfig $(pwd)
Launch the node:
bazel run //:launch
Run a kubectl command:
bazel run //metropolis/cli/dbg -- kubectl describe