Bazel: Release 2.0 - December 2019

[dslomov]

Cut date 2019-12-02.

[aehlig]

Status of Bazel 2.0

• Target baseline: Dec 2, 2019
• Expected release date: Dec 16, 2019
• List of release blockers

To report a release-blocking bug, please file a bug using the Release blocker label, and cc me.

Task list:

• [X] Update GitHub issues for incompatible changes
• [X] Pick release baseline: db0e32ca6296e56e5314993fe9939bc7331768ec
• [X] Create release candidate: https://releases.bazel.build/2.0.0/rc2/index.html
• [X] Check downstream projects: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1303
• [X] [Create draft release announcement](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit#heading=h.2ivbhcw7qevn)
• [X] Send for review the release announcement PR: https://github.com/bazelbuild/bazel-blog/pull/210
• [X] Push the release, notify package maintainers.
• [X] Update the documentation
• [X] Push the blog post
• [X] Update the release page

[aehlig]

The nightly tests of the last days look equally broken—mainly due to downstream projects not aware of the removal of native maven_jar. So we can as well take the latest nightly; since the only commit after the latest nightly is a bug fix, I will include it as well. So, I'll try 807ed23e4f53a5e008ec823e9c23e2c9baa36d0d as a baseline, but will slip it, if the next nightly is better.

[aehlig]

Slipping baseline to db0e32ca6296e56e5314993fe9939bc7331768ec to fix the release pipeline.

[aehlig]

Created rc2 with baseline https://github.com/bazelbuild/bazel/commit/db0e32ca6296e56e5314993fe9939bc7331768ec and no cherry-picks: https://releases.bazel.build/2.0.0/rc2/index.html

[aehlig]

Run of downstream projects pretty broken as a lot of projects are not yet prepared for the removal of native maven_jar.

[jin]

Looks like #10000 missed the baseline cut by a few hours. Could we please cherry-pick https://github.com/bazelbuild/bazel/commit/85e84f7812f04bc0dbc36376f31b6dd2d229b905 into the release?

@bchang @donaldchai

[aehlig]

Creating rc3 with same baseline and https://github.com/bazelbuild/bazel/commit/85e84f7812f04bc0dbc36376f31b6dd2d229b905 cherry-picked.

[jin]

Thanks @aehlig!

[aehlig]

• rc3 available at https://releases.bazel.build/2.0.0/rc3/index.html
• run of downstream projects at https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1301

[davido]

Protobuf is also broken.
protocolbuffers/protobuf#6970

The issue with replacing of native maven_jar usages with {java|jvm}_maven_import_external is that it is conflicting with --incompatible_load_java_rules_from_bzl and is producing broken code. It's using java_import internally, but is not generating this line:

# This line is missing
load("@rules_java//java:defs.bzl", "java_import")

The breakage was flagged by @ejona86 in https://github.com/bazelbuild/bazel/issues/8746#issuecomment-541246615 and as the consequence, this issue was filed: [1].

IOW, there is currently no way forward strategy for such replacement. That why, the migration of native maven_jar is not ready yet, and consistently, the right course of action would be:

a. Try to fix: [1] in upcoming 2.0 release.
b. In case a. is not possible, roll back removal of maven_jar in Bazel 2.0 and schedule it for a later release, but only until after [1] is fixed.

[1] https://github.com/bazelbuild/bazel/issues/10046

[jin]

incompatible_load_java_rules_from_bzl hasn't been enabled in Bazel 2.0. We can definitely make sure that that rules_java is automatically loaded in 2.x, and ready by the time incompatible_load_java_rules_from_bzl is enforced.

We're also extracting the Starlark jvm rules out of Bazel (https://github.com/bazelbuild/rules_jvm_external/pull/299), which allows for a separate release cadence from Bazel.

[davido]

I tried using Bazel 2.0.0rc3 but after fetching bazel-2.0.0rc3-installer-linux-x86_64.sh and installing it locally, it is telling me that I have to download bazel binary again. I filed this issue.

[aehlig]

New run on the downstream projects, as some have been fixed: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1303

[jin]

@aehlig all of the known failures from maven_jar are now migrated, AFAICT.

[Kernald]

I just spotted a typo in the new .bazelversion handling: #10388 might be interesting to cherry-pick (absolutely not critical though, I don't know what's the policy on those kind of minor fixes after a cut)

[philwo]

Hi @aehlig,

please cherry-pick these commits into rc4 to fix the reported issues with the wrapper:

• https://github.com/bazelbuild/bazel/commit/84eae2ff550c433a3d0409cf2b5525059939439d
• https://github.com/bazelbuild/bazel/commit/d5ae460f1581ddf27514b4be18255481b47b4075

[aehlig]

Creating rc4 with baseline db0e32ca6296e56e5314993fe9939bc7331768ec and cherry picks

• 85e84f7812f04bc0dbc36376f31b6dd2d229b905
• 84eae2ff550c433a3d0409cf2b5525059939439d
• d5ae460f1581ddf27514b4be18255481b47b4075

[aehlig]

• rc4 is available at https://releases.bazel.build/2.0.0/rc4/index.html
• run of the downstream projects at https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1319

[aehlig]

Looking at the downstream projects, the following is to be noted.

• There was some infrastructure failure, hence the retries; @philwo is investigating the root cause, but in either way, this is unrelated to bazel release candidate.
• rules_cc is a known issue. https://github.com/bazelbuild/rules_cc/commit/cd7e8a690caf526e0634e3ca55b10308ee23182d adds a test for a feature that was only introduced in https://github.com/bazelbuild/bazel/commit/949e806a4b4e24b36d6d41cc4f9721c8f5ab63ad and hence is not part of bazel 2.0.0. Users who which to use rules_cc with bazel 2.0.0 should use version https://github.com/bazelbuild/rules_cc/commit/01d4a48911d5e7591ecb1c06d3b8af47fe872371 of rules_cc.
• rules_rust is broken in stardoc invocation; this invocation makes invalid assumptions of how to map repositories to paths in the output root: Stardoc documentation generation failed: File all.bzl imported '@io_bazel_rules_rust//rust:toolchain.bzl', yet external/io_bazel_rules_rust/rust/toolchain.bzl was not found, even at roots [., external/docs]. despite @io_bazel_rules_rust being the main repository.
• rules_nodejs is also broken in stardoc like rules_rust and, on top, stardoc rightly complains that the doc string for node_repositories does not have a one-line summary.

So, according to our current policy, these breakages are not blocking. So, unless new problems are reported on the bug, I intend to release on late Thursday or early Friday (Munich time).

[aehlig]

Bazel 2.0 has been released, see https://github.com/bazelbuild/bazel/releases/tag/2.0.0

[aehlig]

cc @vbatts @petemounce @excitoon as you're maintaining a bazel package

[uri-canva]

cc @mboes, @danjuv

[philwo]

@dslomov If you agree, I could create a patch release for Bazel 2.0 with https://github.com/bazelbuild/bazel/commit/2a8cc7075f741721563efd9dc050ca3458cde30b included to address https://github.com/bazelbuild/bazel/issues/10356#issuecomment-582397149.

[dslomov]

@philwo sgtm

[philwo]

I'm preparing Bazel 2.0.1 with two cherry-picks:

https://github.com/bazelbuild/bazel/commit/9a823d9dab82631ff4600eff38d597807e8d1221: Prevent NPE on backwards seek on Chunker.
https://github.com/bazelbuild/bazel/commit/2a8cc7075f741721563efd9dc050ca3458cde30b: Do not fail or print errors when Shellzelisk cannot find a requested Bazel binary, if tools/bazel exists.

RELEASE_NUMBER=2.0.1
BASELINE_COMMIT=50514fc6c125750d7063d7feea2c302a44d2db6e
git clone https://github.com/bazelbuild/bazel.git ~/bazel-release-$RELEASE_NUMBER
cd ~/bazel-release-$RELEASE_NUMBER
scripts/release/release.sh create $RELEASE_NUMBER $BASELINE_COMMIT \
    9a823d9dab82631ff4600eff38d597807e8d1221 \
    2a8cc7075f741721563efd9dc050ca3458cde30b

[philwo]

Bazel 2.0.1rc1 is now available for those that want to try it out.

You can download it from:
https://releases.bazel.build/2.0.1/rc1/index.html

[chenrui333]

Just curious what might be the reason why people cannot move to Bazel 2.1.0?

[philwo]

@chenrui333 There shouldn't be any reason (there are no intentionally breaking changes, or accidental breaking changes that we could detect via our CI), but just in case that Bazel 2.1 has a regression for some Bazel 2.0 users, I think the patch release is nice and doesn't do harm. :) It might also be easier to qualify for users who have stricter validations for their upgrade, e.g. in case of industry regulations.

Personally, I would of course just upgrade to Bazel 2.1. 😊

[chenrui333]

I am mostly thinking from maintenance efforts from you guys perspective (you guys are doing awesome job 👍 ).

Thanks for clarifying it!

[vbatts]

i've cut the release for fedora/centos/RHEL as a package named 'bazel2' so folks can opt-in to the upgrade.