Open jasonbdly opened 1 month ago
Since this seems to be more closely related to the upstream bazel_lib package, I submitted an issue there as well: https://github.com/bazel-contrib/bazel-lib/issues/964. Hopefully this gets some discussion started about how Windows support could be added.
Yes, this needs to be fixed in bazel-lib before it can be fixed here.
FYI windows support here is close to non-existent as we don't have the resources to develop for windows. i would not expect this to work even if we fix zstd toolchain.
Got it, thanks for clarifying!
For any other readers having similar issues, I was able to work around the lack of direct support for Windows with a few tweaks to my setup and workflow:
Enabled WSL Integration for my primary WSL2 linux distro:
Cloned my repo into my WSL2 distro and started VSCode from that directory via code .
.
With these settings the development experience is pretty close to developing directly on the host machine, but the build process occurs within a linux environment, including the execution of the rules in this package. With the Docker CLI exposed to WSL, the linux environment can also push the built images to your local registry and otherwise interact normally with the Docker Desktop installation.
Some things to note:
/usr/local/bin
directory and updating my PATH
: https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#installationgo install
option to install this: https://github.com/bazelbuild/buildtools/blob/main/buildifier/README.md#setup.
go install
location to your PATH
: /home/<username>/go/bin
The only thing I haven't figured out yet is how best to expose the directory within WSL to other host machine apps. I prefer to use Sublime Merge for repo management (I'll probably just install it directly in the WSL instance in the end), but for now VSCode's built-in repo management utilities are good enough.
I'm working on migrating a bunch of disparate shell build scripts to Bazel. The project consists of a set of grpc servers written in Go and exposed as their own binaries, each of which are subsequently built into
Containerfile
images running on top ofdebian:bookworm-slim
, and spun up in a local Kubernetes cluster via Docker Desktop.The problem I'm running into occurs when attempting to build the
oci_image
target for any of these grpc servers (with the recommended toolchain_resolution_debug flag enabled):IIUC, it looks like
aspect_bazel_lib
doesn't provide a toolchain for zstd that works on Windows? Is this a legitimate support issue for Windows, or have I misconfigured something somewhere? Are there any workarounds I can attempt to use? Is there any additional information I can provide to narrow this down? This may be at least partially related to https://github.com/bazel-contrib/rules_oci/issues/714, but I'm not totally sure.Here's the relevant
BUILD
file for reference:And the
MODULE.bazel
file:The output from
bazelisk version
: