Bazel CI: name 'http_jar' is not defined

[meteorcloudy]

f5b7122 is causing some downstream projects to fail with

ERROR: /var/lib/buildkite-agent/builds/bk-docker-9477/bazel-downstream-projects/rules_kotlin/WORKSPACE:24:1: name 'http_jar' is not defined
--
  | ERROR: Error evaluating WORKSPACE file
  | ERROR: error loading package 'external': Package 'external' contains errors
  | Traceback (most recent call last):
  | File "bazelci.py", line 1787, in <module>
  | sys.exit(main())
  | File "bazelci.py", line 1771, in main
  | incompatible_flags=args.incompatible_flag,
  | File "bazelci.py", line 471, in execute_commands
  | print_bazel_version_info(bazel_binary, platform)
  | File "bazelci.py", line 614, in print_bazel_version_info
  | + ["--nomaster_bazelrc", "--bazelrc=/dev/null", "info"]
  | File "bazelci.py", line 1044, in execute_command
  | return subprocess.run(args, shell=shell, check=fail_if_nonzero, env=os.environ).returncode
  | File "/usr/local/lib/python3.6/subprocess.py", line 438, in run
  | output=stdout, stderr=stderr)

rules_k8: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/746#8b8ef6ea-124d-4417-9482-ef461672483b

rules_kotlin: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/746#1ceaa1e6-5ee0-4723-986b-a51834774b87

TensorFlow: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/746#30302152-04d2-47e2-9577-d3e36a113962

Please help fixing their WORKSPACE files. @aehlig

[aehlig]

The native http_archive, http_jar, http_file, etc, were deprecated for almost 11 months now and the corresponding flag --incompatible_remove_native_archive has been flipped over two months ago. Admittedly, this only warned about actual uses of these native rules, not dead declarations.

In this case, the projects are broken by calling a repositories() function from a roughly a year old version of their dependencies (like bazel_toolchains). A quick fix would be to to add a patch argument to the http_archive importing the old version of bazel_toolchains that removes all the not needed indirect dependencies---or simply calls the Starlark version of http_file instead. A clean way would be update to a more recent version of bazel_toolchain, which, however, requires domain-specific knowledge.

[meteorcloudy]

I have two questiones:

1. How could users notice f5b7122 is going to break them?
2. How could they test with the release version of Bazel when trying to fix it? (There is no incompatible flag guarding f5b7122 )

[aehlig]

Side remark: at least in the case of tensorflow, this "breakage" is purely an artifact of our test procedure. Tensorflow dispatches on the version of bazel and only uses a version of bazel_toolchains using the native.http_file if it believes that the bazel version is older than 0.19. As, however, our snapshot versions do not have a proper version number embedded, our bazel at HEAD is believed to be older(!!) than bazel 0.19. So the breakage happens in code path that will never be executed in by any user of a released version of bazel. (A corollary of this is that the code path used by actual users is actually untested.)

[meteorcloudy]

@aehlig Thanks for the investigation, TensorFlow now has a minimal Bazel version requirement of 0.19, I will send a fix to remove the old toolchain.