You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 2, 2023. It is now read-only.
In bazelbuild/bazel@87fb462, I changed Bazel's platform rule to be non-configurable: this is a core goal of the Platforms API, since the target platform is part of the configuration, and in some changes appearing in the near future allowing the platform to change based on the configuration will lead to a conceptual dependency cycle (as opposed to a bazel target dependency cycle, or a Java class dependency cycle, this is a semantic issue and not syntactic).
Unfortunately, the //platforms:image_transition target in rules_docker is using configuration in the definition, specifically due to the use of a label_setting target, which I think is acting as an alias for the actual target CPU and OS constraints. This is leading to several failures in other projects which depend on rules_docker (see buildfarm/buildfarm#1446 and buchgr/bazel-remote#700 for examples).
The immediate workaround is probably for projects to use the --@io_bazel_rules_docker//transitions:enable=false flag to disable the transition which sets //platforms:image_transition as the target platform, although that's a bit heavy-handed.
I have re-read PR #1963, which adds this behavior, and it looks like this exists to support the architecture attribute on image rules. In this case, the correct long-term fix is to integrate the change_platform transition from Standard Platform Transitions, which we are busy implementing currently and should be available shortly.
The text was updated successfully, but these errors were encountered:
In bazelbuild/bazel@87fb462, I changed Bazel's
platform
rule to be non-configurable: this is a core goal of the Platforms API, since the target platform is part of the configuration, and in some changes appearing in the near future allowing the platform to change based on the configuration will lead to a conceptual dependency cycle (as opposed to a bazel target dependency cycle, or a Java class dependency cycle, this is a semantic issue and not syntactic).Unfortunately, the
//platforms:image_transition
target in rules_docker is using configuration in the definition, specifically due to the use of alabel_setting
target, which I think is acting as an alias for the actual target CPU and OS constraints. This is leading to several failures in other projects which depend on rules_docker (see buildfarm/buildfarm#1446 and buchgr/bazel-remote#700 for examples).The immediate workaround is probably for projects to use the
--@io_bazel_rules_docker//transitions:enable=false
flag to disable the transition which sets//platforms:image_transition
as the target platform, although that's a bit heavy-handed.I have re-read PR #1963, which adds this behavior, and it looks like this exists to support the
architecture
attribute on image rules. In this case, the correct long-term fix is to integrate thechange_platform
transition from Standard Platform Transitions, which we are busy implementing currently and should be available shortly.The text was updated successfully, but these errors were encountered: