FYI: rules_contest has been fixed - the failure was due to the flag flip of --incompatible_disallow_empty_glob.

rules_ruby are fixed in 0.14.1, the issue was usage of --incompatible_remote_results_ignore_disk in tests.

rules_wasm fixed: #3268.

Filed bazelbuild/bazel#24499 to discuss a better solution, but was able to just duplicate some data as a workaround. The breaking change stems from bazelbuild/bazel@27487cf which causes the patch tool for http_archive to always receive a -p option, even when patch_args is empty. Is that an issue for anybody else? Or was that just because of my abuse of patch_tool.

[email protected] contains a fix.

@ouillie Can you use patch_cmds instead? That's the recommended way to run arbitrary commands.

[email protected]

Maintainers: @EdSchouten

• [email protected] - :centos: CentOS 7 - Run example test module
• [email protected] - :debian: Debian 10 Buster (OpenJDK 11, gcc 8.3.0) - Run example test module
• [email protected] - :darwin: macOS - Run example test module
• [email protected] - :ubuntu: Ubuntu 20.04 LTS - Run example test module

It looks like all of these breakages are caused by jsonnet, not rules_jsonnet. Unfortunately, I am not able to make able to make contributions to that repository directly. Sorry!

Once these build failures are addressed on the jsonnet side, I'd be more than happy to cut a new release of rules_jsonnet that depends on it.

@EdSchouten Yes, jsonnet is also identified in #3056
@mortenmj Can you help fixing this since you contributed the initial BCR module.

rules_sh, rules_nixpkgs and rules_haskell all fail with the same error:

	File "/var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/2bbac50a5364a2d14c5e3065383ed7e2/external/rules_sh+/sh/posix.bzl", line 11, column 55, in <toplevel>
		load("@bazel_tools//tools/cpp:lib_cc_configure.bzl", "get_cpu_value")
Error: file '@bazel_tools//tools/cpp:lib_cc_configure.bzl' does not contain symbol 'get_cpu_value'

We were relying on this macro, but apparently it has been removed and the one in rules_cc is private. We are going to vendor a copy of this macro into our rules to solve this, but maybe others are also having this issue and copying this code around seems not very maintainable. WDYT?

@avdv I think we could expose this in https://github.com/bazelbuild/rules_cc/blob/8395ec0172270f3bf92cd7b06c9b5b3f1f679e88/cc/toolchains/toolchain_config_utils.bzl#L22

Sent bazelbuild/rules_cc#283

rules_flex fix: #3285

rules_Synology will take a few days to fix: I butchered the bcr template and I’m afk 3 days. I can’t reproduce the failure but have a fix for a guess of the cause into v0.0.3

rules_Synology will take a few days to fix: I butchered the bcr template and I’m afk 3 days. I can’t reproduce the failure but have a fix for a guess of the cause into v0.0.3

After some templating issues, #3330 brings in v0.1.1 (via chickenandpork/rules_synology#176) which might have a fix for rules_synology -- unfortunately, I cannot repro, so I'm guessing based on the error message.

@meteorcloudy can we pass --check_direct_dependencies=off in this CI job? in my case it's a bcr module where that as an error is checked in to the .bazelrc, so it's a false positive https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/72#019367c7-9404-453f-9c57-66b13aca10d9

@keith --check_direct_dependencies is now set to warning when the Bazel version is changed, the new error from rules_apple_linker suggests rules_apple might need to be updated.

@meteorcloudy what would be a procedure to remove [email protected] from this check? I don't plan to add support for Bazel >=8 to the package