- Adds a gen_compile_commands.py script to generate a `compile_commands.json` for clangd, similar to Linux's `scripts/clang-tools/gen_compile_commands.py`
- Configures the dev container to generate the database before the editor is opened
- Adds `clangd` vscode extension to the dev container (and installs `clangd` in the default image)
- Updates CONTRIBUTING.md with instructions for generating a `compile_commands.json` database when *not* using a dev container
Also switches to a less confusing link for the Dev Containers extension.
Long-term, we want to clean up our use of Bazel so that a container isn't necessary to build gVisor. As a stop-gap, let's make the out-of-box VSCode experience a little smoother by configuring a GOPACKAGESDRIVER for gopls out-of-the-box, and recommending using a dev container.
The advantage of recommending a dev container is that we can configure an on-start command to run `@io_bazel_rules_go//go` through Bazel *before* gopls starts, which installs the correct Go version in the container automatically. And in the future we can configure a `compile_commands.json` to be generated at startup for clangd (for the C++ tests).
- Updates the dev container configuration to install the Go extension and fetch the Go compiler at startup.
- Adds a settings.json that configures gopls to run a GOPACKAGESDRIVER through bazel, making LSP work for the auto-generated code.
- Updates the docs to explain how to get gopls working with or without a dev container, and marks GOPATH as "not recommended"
- Install `buildifier` in the default container, as used by the Bazel vscode extension for formatting BUILD files
- **checkescape: improve error output**
The output now includes stderr on failure e.g.:
```
checkescape: tools/checkescape/test2/test2.go:98:6: stack: possible split on function entry (2 omitted) → (possible, error running "external/rules_go++go_sdk+main___download_0/bin/go tool objdump bazel-out/k8-fastbuild-ST-04c87098fb12/bin/tools/checkescape/test2/test2.a": exit status 2 (go: no such tool "objdump")) (GOOARCH=amd64, GOOS=linux)
```
Simplify various bits of the implementation while I'm here:
- Use a set of strings rather than a list to avoid some O(n) operations.
- Use `CommandContext` to ensure proper cleanup.
- Remove stderr pipe and goroutine by setting `Stderr` to a
`bytes.Buffer`.
- Use `bufio.Scanner` instead of manually calling
`(*bufio.Reader).ReadString` and handling errors.
- Remove `NextLine` loop label.
- **go_stateify: plumb go binary to goimports**
This avoids go_stateify relying on `go` being available outside of the
bazel sandbox.
- **Update Go to 1.25.5**
Reduce duplication of the version information in various places:
- Use `go_sdk.from_file` instead of repeating the version encoded in
`go.mod` in `MODULE.bazel`.
Add a workaround to allow `objdump` to be lazily compiled in the manner
introduced in https://go.dev/issue/71867 when invoked under bazel in
checkescape.
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/12452 from tamird:update-go 6c7f6400f5d3ea883096eef18d365c97f875bc68
PiperOrigin-RevId: 853572845
- Deletion of the WORKSPACE file. Dependencies are now managed in the MODULE.bazel file.
- Removal of --noenable_bzlmod and --enable_workspace from .bazelrc to enable bzlmod.
- Update paths in MODULE.bazel to be relative to the repository root.
Specifically, build using bazel WORKSPACE. Bazel modules is still not
used and requires further migration.
This updates some dependencies to make them compatible with Bazel 8,
which in turn requires explicitly adding some new dependencies to
support new versions. In some cases existing patches no longer applied
and had to be updated. A new patch was added to remove windows
toolchains from coral-crosstools, because that functionality requires
lots of bazel intrinsics that are no longer defined.
At least on my machine, when //vdso:vdso was a dependency (not targetted
explicitly), the Gold linker specified in `vdso_linker_option` failed to
be found (bazel build //vdso worked); however this led me to discover
that the Gold linker is deprecated, hence using it is removed entirely.
To make the repo compatible with bazelisk out of the box, a bazelversion
file has been added.
The key highlight from the release notes:
Build without the Bytes for builds using remote caching and/or remote
execution is now enabled by default (i.e. --remote_download_outputs
defaults to toplevel). This means that Bazel will no longer try to
download any intermediate outputs from the remote server, but only the
outputs of requested top-level targets instead. This significantly
improves build performance. Bazel now also handles the case of an
artifact falling out of the remote cache gracefully, by rewinding the
build.
Signed-off-by: Andrei Vagin <[email protected]>
Instead of lying to clang about the targeted system, we can install the
necessary package only on x86_64 machines. Our tooling supports multiarch
packages (see tools/images.mk).
PiperOrigin-RevId: 591385576
This patch adds the EROFS rootfs support. No gofer process will be
created for the container, when there is no need to pass through host
files into a container via the gofer process. Annotations for rootfs
are also introduced to provide extra information, including the mount
source, mount type and overlay config. Additionally, busybox-static
is added to the default image and will be used to build the EROFS
rootfs images during the test.
Updates #8956
Signed-off-by: Tiwei Bie <[email protected]>
This patch adds an EROFS test which checks that the checksums we get
from the target directory in container are identical with the ones
got from the source directory that we used to create the EROFS images.
erofs-utils is also added to the default image and will be used to
build the EROFS images during the test.
Signed-off-by: Tiwei Bie <[email protected]>
A recent change stopped using the correct file (the export data, not the
archive) and checklocks started failing. Unfortunately, this was suppressed,
since the filter command was not failing with findings.
This change fixes that problem and adds a test to ensure that this cannot
happen again. If nogo starts failing to identify problems, the sanity_test in
nogo/sanity will also start to fail.
This change also requires updating the WORKSPACE to the latest rules_go and
Go version, in order to pick up the fixed go_tools. The latest rules_go in
turn required an updated bazel, which in turn required a minor change in the
coverdata implementation.
Fixing the fact propagation brought forward a number of problems with caching
for bazel workers. Its unclear whether this was a core worker issue or whether
some caching was broken, but the situation was basically undebugable. Instead,
the way facts are stored and loaded is optimized to be able to remove the use
of workers altogether and ideally make nogo debuggable.
PiperOrigin-RevId: 426327186
...and a bunch of other things as I worked through the rot. Notably:
- Upgrade to bazel 4.0.0
- Upgrade to Go 1.15.7
Remove go_branch stderr suppression; this made it quite difficult to see
what was failing while developing this patch.
PiperOrigin-RevId: 355257833
A few images were broken with respect to aarch64. We should now
be able to run push-all-images with ARCH=aarch64 as part of the
regular continuous integration builds, and add aarch64 smoke tests
(via user emulation for now) to the regular test suite (future).
PiperOrigin-RevId: 346685462
Recursive make is difficult to follow and debug. Drop this by using
internal functions, which, while difficult, are easier than trying to
following recursive invokations.
Further simplify the Makefile by collapsing the image bits and removing
the tools/vm directory, which is effectively unused.
Fixes#4952
PiperOrigin-RevId: 346569133
Using "--no-cache-dir" flag in pip install ,make sure dowloaded packages
by pip don't cached on system . This is a best practise which make sure
to fetch ftom repo instead of using local cached one . Further , in case
of Docker Containers , by restricing caching , we can reduce image size.
In term of stats , it depends upon the number of python packages
multiplied by their respective size . e.g for heavy packages with a lot
of dependencies it reduce a lot by don't caching pip packages.
Further , more detail information can be found at
https://medium.com/sciforce/strategies-of-docker-images-optimization-2ca9cc5719b6
For some reason these tests were broken when run via the bazel docker
container. The mechanism used was a bit crazy (self-extracting bundle),
so convert them to use straight-forward starlark rules. This has the
added advantaged that they are now independent tests.
This adapts the merged website repository to use the image and bazel
build framework. It explicitly avoids the container_image rules provided
by bazel, opting instead to build with direct docker commands when
necessary.
The relevant build commands are incorporated into the top-level
Makefile.
This change moves all Docker images to a standard location, and abstracts the
build process so that they can be maintained in an automated fashion. This also
allows the images to be architecture-independent.
All images will now be referred to by the test framework via the canonical
`gvisor.dev/images/<name>`, where `<name>` is a function of the path within the
source tree.
In a subsequent change, continuous integration will be added so that the images
will always be correct and available locally.
In the end, using `bazel` for Docker containers is simply not possible. Given
that we already have the need to use `make` with the base container (for
Docker), we extend this approach to get more flexibility.
This change also adds a self-documenting and powerful Makefile that is intended
to replace the collection of scripts in scripts. Canonical (self-documenting)
targets can be added here for targets that understand which images need to be
loaded and/or built.
PiperOrigin-RevId: 308322438
