rules_docker
rules_docker copied to clipboard
py_binary stops working after adding rules_docker dependencies
🐞 bug report
Affected Rule
The issue is caused by the function:load("@io_bazel_rules_docker//repositories:deps.bzl", container_deps = "deps")
container_deps()
If I call container_deps
suddently all my py_binary
rules stop working.
Is this a regression?
Don't think soDescription
I have a repo with multiple binaries being built. Some of them are python using the py_binary
rule. If I introduce the boilerplate to add rules_docker
in the WORKSPACE
file, the py_binary
targets can't be built.
🔬 Minimal Reproduction
See a minimal example here: https://github.com/chaosct/error_py_binary_rules_docker
🔥 Exception or Error
> bazel build --define=VERBOSE_LOGS=1 //...
INFO: Build option --define has changed, discarding analysis cache.
ERROR: /Users/protopixel/Documents/scratch/poc_f/BUILD:5:10: While resolving toolchains for target //:pre-commit: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.
ERROR: Analysis of target '//:pre-commit' failed; build aborted:
INFO: Elapsed time: 0.245s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (24 packages loaded, 248 targets configured)
🌍 Your Environment
Operating System:
OSX 11.4 (M1)
Output of bazel version
:
Bazelisk version: v1.11.0
Build label: 5.1.1
Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Apr 8 15:58:49 2022 (1649433529)
Build timestamp: 1649433529
Build timestamp as int: 1649433529
Rules_docker version:
http_archive(
name = "io_bazel_rules_docker",
sha256 = "27d53c1d646fc9537a70427ad7b034734d08a9c38924cc6357cc973fed300820",
strip_prefix = "rules_docker-0.24.0",
urls = ["https://github.com/bazelbuild/rules_docker/releases/download/v0.24.0/rules_docker-v0.24.0.tar.gz"],
)
Anything else relevant?
Ok, so if I run the build with --toolchain_resolution_debug=@bazel_tools//tools/cpp:toolchain_type
I can see that if container_deps
is not called the toolchain ins selected:
INFO: ToolchainResolution: Type @bazel_tools//tools/cpp:toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @local_config_cc//:cc-compiler-darwin_arm64
But if I call container_deps
the toolchain is not selected:
INFO: ToolchainResolution: Type @bazel_tools//tools/cpp:toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @local_config_cc//:cc-compiler-darwin_arm64; mismatching values: arm64
Also I can confirm that this works without problems on a Ubuntu 18.04 , x86_64.
Also ran into the same error this morning after upgrading from 0.22.0
to 0.24.0
using the following rules in my build file:
- container_layer
- container_run_and_commit
- container_image
- container_push
I also tested against 0.23.0
and the same error happens so it seems like the dependency change was introduced there. In my case the setup is similar:
macOS 11.6.5 on an intel CPU
Command I'm running (with the actual target anonymized)
bazel run //services/myservice:image --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64
Bazel version
Build label: 5.1.1-homebrew
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jan 1 00:00:00 1980 (315532800)
Build timestamp: 315532800
Build timestamp as int: 315532800
Tried both of these docker rules versions and got the same error before rolling back to 0.22.0 where I don't hit this error:
http_archive(
name = "io_bazel_rules_docker",
sha256 = "85ffff62a4c22a74dbd98d05da6cf40f497344b3dbf1e1ab0a37ab2a1a6ca014",
strip_prefix = "rules_docker-0.23.0",
urls = ["https://github.com/bazelbuild/rules_docker/releases/download/v0.23.0/rules_docker-v0.23.0.tar.gz"],
)
http_archive(
name = "io_bazel_rules_docker",
sha256 = "27d53c1d646fc9537a70427ad7b034734d08a9c38924cc6357cc973fed300820",
strip_prefix = "rules_docker-0.24.0",
urls = ["https://github.com/bazelbuild/rules_docker/releases/download/v0.24.0/rules_docker-v0.24.0.tar.gz"],
)
It is related to https://github.com/bazelbuild/rules_docker/issues/2052 and https://github.com/bazelbuild/rules_docker/issues/2073. There is an open PR (https://github.com/bazelbuild/rules_docker/pull/2068) for disabling transitions.
For what is worth, I did test this with rules_docker
0.22.0
and got the same result, so I'm not sure that it is the same issue.
What it seems to work in my case is adding a newer version of rules_go
than the one provided by rules_docker
before including rules_docker
.
in WORKSPACE
:
# We need to have a newer version of bazel go rules than the one provided by rules_docker to detect OSX M1 arch (arm64)
# correctly. If we don't, we will get a cryptic build error related to toolchains.
http_archive(
name = "io_bazel_rules_go",
sha256 = "f2dcd210c7095febe54b804bb1cd3a58fe8435a909db2ec04e31542631cf715c",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.31.0/rules_go-v0.31.0.zip",
"https://github.com/bazelbuild/rules_go/releases/download/v0.31.0/rules_go-v0.31.0.zip",
],
)
load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
go_rules_dependencies()
go_register_toolchains(version = "1.18")
# docker
http_archive(
name = "io_bazel_rules_docker",
sha256 = "27d53c1d646fc9537a70427ad7b034734d08a9c38924cc6357cc973fed300820",
strip_prefix = "rules_docker-0.24.0",
urls = ["https://github.com/bazelbuild/rules_docker/releases/download/v0.24.0/rules_docker-v0.24.0.tar.gz"],
)
load(
"@io_bazel_rules_docker//repositories:repositories.bzl",
container_repositories = "repositories",
)
container_repositories()
load("@io_bazel_rules_docker//repositories:deps.bzl", container_deps = "deps")
container_deps()
I also am facing with this issue (M1), bazel 5.1.1 , rules_docker-0.24.0 and go_register_toolchains(version = "1.18"). And I found a warning message below:
WARNING: Download from https://golang.org/dl/?mode=json&include=all failed: class java.io.IOException connect timed out
Analyzing: target //...
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!
This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"