| commit | 6ebdc418f3c4799c12368e34ea78dc9c9757fb54 | [log] [tgz] |
|---|---|---|
| author | Serge Bazanski <serge@nexantic.com> | Fri May 21 16:25:55 2021 +0200 |
| committer | Sergiusz Bazanski <serge@nexantic.com> | Fri May 28 15:53:36 2021 +0000 |
| tree | 55dcecf2fda5b992c703dea87ef2cea495f6ffe0 | |
| parent | 67483ded56f26ced15581d7a87314d776cf5ecb0 [diff] |
RFC: build/analysis: add commentwrap This adds a Go analyzer which limits the length of comment lines to 80 characters. Rationale: Monogon currently follows gofmt style. Gofmt in itself is already quite opinionated, but one thing it explicitly does not check for is maximum line length. This implements a limit for the maximum length of a comment line in Go source within Monogon. It explicitly does not limit code line length, as these can be handled much more easily by soft reflows. The tool used, github.com/corverroos/commentwrap, will now be automatically ran by our nogo pass, and prevent any line of commnets within Go to be longer than 80 characters, with the exception of: - cgo/generate directives - TODOs - indented comments (eg. sample code or long URLs) Downsides: 1. We have to reformat the entire codebase. CR/67 does this. 2. We end up with a bulk Git commit that will pollute Git history. A followup CR attempts to resolve this by using Git's ignoreRevsFile functionality. 3. There's currently no integration with IntelliJ and no way to automatically reformat code. If this RFC gets approved, a follow up CR will be created that adds integration/automation to make this easier to work against. Open questions: 1. Is 80 characters the right limit? I, personally, quite like it, but am willing to compromise on line length. Change-Id: I063d64596ca5ef038a8426c6b9f806b65c18451e Reviewed-on: https://review.monogon.dev/c/monogon/+/66 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 //...