Skip to content
This repository has been archived by the owner on Oct 2, 2023. It is now read-only.

py_binary stops working after adding rules_docker dependencies #2075

Closed
chaosct opened this issue Apr 29, 2022 · 7 comments
Closed

py_binary stops working after adding rules_docker dependencies #2075

chaosct opened this issue Apr 29, 2022 · 7 comments
Labels
Can Close? Will close in 30 days unless there is a comment indicating why not

Comments

@chaosct
Copy link

chaosct commented Apr 29, 2022

馃悶 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 so

Description

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?

@chaosct
Copy link
Author

chaosct commented Apr 29, 2022

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.

@wwsean08
Copy link

wwsean08 commented May 2, 2022

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"],
)

@psalaberria002
Copy link

psalaberria002 commented May 3, 2022

It is related to #2052 and #2073. There is an open PR (#2068) for disabling transitions.

@chaosct
Copy link
Author

chaosct commented May 3, 2022

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()

@tanthml
Copy link

tanthml commented Jun 7, 2022

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 //...

@github-actions
Copy link

github-actions bot commented Dec 5, 2022

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!

@github-actions github-actions bot added the Can Close? Will close in 30 days unless there is a comment indicating why not label Dec 5, 2022
@github-actions
Copy link

github-actions bot commented Jan 5, 2023

This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"

@github-actions github-actions bot closed this as completed Jan 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Can Close? Will close in 30 days unless there is a comment indicating why not
Projects
None yet
Development

No branches or pull requests

4 participants