Bazel: Release 1.0 - September 2019

[dslomov]

Target RC date - September 3rd, 2019.
See the blog post for some details

[kkiningh]

There's quite a few issues with the 1.0 tag left, including some that seem fairly significant. Which ones does the Bazel team still expect to address before the release?

[dslomov]

There's quite a few issues with the 1.0 tag left, including some that seem fairly significant. Which ones does the Bazel team still expect to address before the release?

We will do a review of those. If you think a specific issue is particularly important to address for 1.0, please comment on it.

[katre]

Note that aaff22cadcb59f5497b9a84879ca2ca2a3b1323b and 7ed66f7a31bf5c174f05c295c07fe90cc2aaf2b9 are rollbacks of commits that are present in 0.29.0. They should be rolled forward again before 1.0 is cut, but we need to make sure of that when choosing the baseline.

(They were rolled back due to an internal issue that does not affect Bazel. See http://b/138789815 for the internal discussion.)

[cgruber]

In particular, both early phases of the rules_kotlin and rules_android roadmaps seem not to have any indications of their progress, and I have had several assurances that their "mid-2019" goals would roll out as a part of the Bazel 1.0 process. Can someone please confirm this, or otherwise inform folks who are waiting on those?

[dslomov]

Current list of blockers is https://github.com/bazelbuild/bazel/labels/bazel%201.0

[dslomov]

97a8264 is a 1.0 baseline I am going to try. Failing downstream projects:

• TensorFlow: https://github.com/bazelbuild/bazel/issues/7362#issuecomment-527115823
  
  
  
  • Need fixes from TensorFlow
  
  
• rules_foreign_cc: https://github.com/bazelbuild/rules_foreign_cc/pull/309
  
  
  
  • Need fix from rules_foreign_cc
  
  
• rules_typescript: fix in flight
• rules_nodejs: rules_nodejs/.bazelci/presubmit.yml was changed, a wrong target was added but the following fixes didn’t get in because the pipeline was red for some other reason. Filed https://github.com/bazelbuild/rules_nodejs/issues/1096

[dslomov]

Stuck on https://github.com/bazelbuild/continuous-integration/pull/810, will retry the build once that goes in.

[dslomov]

Cherry-picking a0e3bb207fe2044120a2555a37162ee1f2b17500 - fix for #9327

[dslomov]

 ./scripts/release/release.sh create --force_rc=2 1.0.0 97a8264 a0e3bb2 

[katre]

I also cherrypicked 5c02b92c45b5422971b3164685d9edb771367a1b into 0.29.1, is that in 1.0.0?

[dslomov]

I also cherrypicked 5c02b92 into 0.29.1, is that in 1.0.0?

I believe so.

[dslomov]

1.0.0rc2 is available: https://releases.bazel.build/1.0.0/rc2/index.html
Downstream projects: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1183.
Failures:

• rules_foreign_cc: https://github.com/bazelbuild/rules_foreign_cc/pull/309
• TensorFlow: https://github.com/bazelbuild/bazel/issues/7362#issuecomment-527115823

[davido]

It seems, that 1.0.0rc2 broke Gerrit (stable-2.14 release):

  ERROR: /home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD:63:1: in java_doc rule //gerrit-extension-api:extension-api-javadoc: 
Traceback (most recent call last):
    File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD", line 63
        java_doc(name = 'extension-api-javadoc')
    File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in _impl
        depset(transitive = [j.java.transitive_...])
    File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in depset
        j.java.transitive_deps
object of type 'JavaSkylarkApiProvider' has no field 'transitive_deps'

It seems to be related to: [1]. This is the place in the code: [2]. This is the complete CI log: [3].

All is fine on 0.29.0 release.

[1] https://github.com/bazelbuild/bazel/issues/7598
[2] https://github.com/GerritCodeReview/gerrit/blob/stable-2.14/tools/bzl/javadoc.bzl#L20-L21
[3] https://gerrit-ci.gerritforge.com/job/Gerrit-verifier-bazel/71542/consoleText

[dslomov]

It seems, that 1.0.0rc2 broke Gerrit (stable-2.14 release):

  ERROR: /home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD:63:1: in java_doc rule //gerrit-extension-api:extension-api-javadoc: 
Traceback (most recent call last):
  File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD", line 63
      java_doc(name = 'extension-api-javadoc')
  File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in _impl
      depset(transitive = [j.java.transitive_...])
  File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in depset
      j.java.transitive_deps
object of type 'JavaSkylarkApiProvider' has no field 'transitive_deps'

It seems to be related to: [1]. This is the place in the code: [2]. This is the complete CI log: [3].

All is fine on 0.29.0 release.

[1] #7598
[2] https://github.com/GerritCodeReview/gerrit/blob/stable-2.14/tools/bzl/javadoc.bzl#L20-L21
[3] https://gerrit-ci.gerritforge.com/job/Gerrit-verifier-bazel/71542/consoleText

Well, yes #7598 is a breaking change in 1.0 (marked as such). Use j[JavaInfo].transitive_deps instead (per backwards compatibility policy and Updating Bazel guidance.

[davido]

I would like to bring to your attention the fact, that 1.0.0rc2 broke IntelliJ plugin. I just wrote this issue.

[kastiglione]

Hi, can this commit be picked into 1.0: https://github.com/bazelbuild/bazel/pull/9371?

On macOS, it affects hermeticity and caching.

[jin]

@davido Looks like the fix is in (https://github.com/bazelbuild/intellij/commit/5f03bde0f02f5d1693a4567dc129230420a30372), and the plugin version with that fix is expected to be released early next week.

[dslomov]

Will cherrypick ada2c55dcc106cd55bafbbe5d9a966e21e4770e0

[dslomov]

rc3:

./scripts/release/release.sh create --force_rc=3 1.0.0 97a8264 a0e3bb2 ada2c55

[dslomov]

rc3: https://releases.bazel.build/1.0.0/rc3/index.html
downstream build: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1197

[dslomov]

Downstream failures:

• Gerrit issues are fixed with https://github.com/GerritCodeReview/gerrit/commit/09c905ef161ec7cfefc2dd5d7bef24049c12504e (thanks @davido!)
• Looking into Tensorflow

[DavidGoldman]

We'll also want to cherry pick #9403 as it helps improving cache hit rates across multiple macOS versions

[dslomov]

Could you explain in more detail which problem #9403 fixes and why it warrants cherry-picking as opposed to waiting for the next release? Is it a serious regression?

[DavidGoldman]

Could you explain in more detail which problem #9403 fixes and why it warrants cherry-picking as opposed to waiting for the next release? Is it a serious regression?

It's not a serious regression but a nice to have given that the issue is caused by having developers on different macOS versions and a new version of macOS will drop next month.

[dslomov]

Could you explain in more detail which problem #9403 fixes and why it warrants cherry-picking as opposed to waiting for the next release? Is it a serious regression?

It's not a serious regression but a nice to have given that the issue is caused by having developers on different macOS versions and a new version of macOS will drop next month.

I say we get in 1.1 then.

[kastiglione]

It means developers on 10.14 and 10.15 will share very little cache. Anything that has wrapped_clang (for example) as an input, will not share cache with the exact same build built for 10.14 vs 10.15, even if Xcode and all other dependencies are identical.

[davido]

I've tested all major use cases with building and testing of Gerrit project with the latest rc3, and it works as expected. I can build and test Gerrit on JDK 8/11 with embedded_jdk11, and on JDK 13 with toolchain_vanilla and that is great!

I've only detected two minor issues. One regression hard coded vanilla_toolchain to produce byte code major version 52 (Java 8) and one bug that wasn't discovered until now, where current_host_java_runtime is not provided in runfiles directory.

There are pending PRs for review for both problems: 1, 2, and we applied workarounds in Gerrit already: a, b.

It would be great, if those fixes could make it in 1.0 release, but they can also be fixed in 1.1 (or later).

[wesleyw72]

https://github.com/bazelbuild/bazel/issues/9439

[dslomov]

9415 is a release blocker, will cherry-pic a fix.

Still waiting for decision on #9270.

[dslomov]

rc4:

 ./scripts/release/release.sh create --force_rc=4 1.0.0 97a8264 a0e3bb2 ada2c55 847df72

[dslomov]

rc4 test run: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1216

[dslomov]

The run is green!

[iirina]

@dslomov Please cherry pick 5cfa0303d6ac3b5bd031ff60272ce80a704af8c2 which fixes the performance regression described in #9270.

[dslomov]

rc5: ./scripts/release/release.sh create --force_rc=5 1.0.0 97a8264 a0e3bb2 ada2c55 847df72 5cfa030

[dslomov]

rc5 test run: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1218

[davido]

It tuns out, that this build spam issue that was reported multiple times already: [1], [2] is actually a regression from remote JDK upgrade to JDK 11 in this commit. See also my detailed analysis of the problem.

After trying to drop Java language level 7 compatibility in Bazel: [3] and Protobuf: [4] projects that was rejected upstream I figured that we can avoid passing mutually exclusive options to Java compiler in non-invasive way, by extending existing ReleaseOptionNormalizer in JavacOptions, in: [5].

Can we consider to apply the fix in java_tools, build new java_tools version 5.2 and cherry-pick it here?

Or, alternatively, could we do official release of java_tools with: [5] merged, but without upgrading Bazel, so that Gerrit project could switch to consuming new java_tools version and that would fix the console spamming issue for Gerrit project.

[1] https://github.com/bazelbuild/bazel/issues/8772
[2] https://bugs.chromium.org/p/gerrit/issues/detail?id=11102
[3] https://github.com/bazelbuild/bazel/pull/9450
[4] https://github.com/protocolbuffers/protobuf/pull/6711
[5] https://github.com/bazelbuild/bazel/pull/9494

[dslomov]

Or, alternatively, could we do official release of java_tools with: [5] merged, but without upgrading Bazel, so that Gerrit project could switch to consuming new java_tools version and that would fix the console spamming issue for Gerrit project.

I like this option. @iirina wdyt?

[1] #8772
[2] https://bugs.chromium.org/p/gerrit/issues/detail?id=11102
[3] #9450
[4] [protocolbuffers/protobuf#6711](https://github.com/protocolbuffers/protobuf/pull/6711)
[5] #9494

[iirina]

I agree, I don't think we should block the release. Submitting [5] and releasing java_tools sounds reasonable to me. You can follow the java_tools release at https://github.com/bazelbuild/java_tools/issues/17

[dslomov]

Will release rc5 today.

[gertvdijk]

Will release rc5 today.

Uhm, I noticed 1.0.0 was just released? https://github.com/bazelbuild/bazel/releases/tag/1.0.0

edit: oh, "1.0.0rc5 as 1.0.0" I guess :smile: :tada:

[dslomov]

Published 1.0.0rc5 as 1.0.0.

• https://github.com/bazelbuild/bazel/releases/tag/1.0.0
• https://releases.bazel.build/1.0.0/release/index.html

Pinging package maintainers: @vbatts @petemounce @excitoon

[zegl]

Congratulations on the 1.0 release, this is a huge milestone for the entire community! 🥇

[vbatts]

Right on, but is there still no solid response for building on aarch64? I am getting increased requests there, but have not gotten it built yet

-------- Original Message --------
On Oct 10, 2019, 07:40, Dmitry Lomov wrote:

Published 1.0.0rc5 as 1.0.0.

• https://github.com/bazelbuild/bazel/releases/tag/1.0.0
• https://releases.bazel.build/1.0.0/release/index.html

Pinging package maintainers: @vbatts @petemounce @excitoon

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[vbatts]

until then, builds kicked off for centos, rhel, and fedora https://copr.fedorainfracloud.org/coprs/build/1052142

[keith]

If there is going to be a patch release I believe https://github.com/bazelbuild/bazel/pull/9376 should be cherry picked which fixes this remote cache regression from 0.29.0 https://github.com/bazelbuild/bazel/issues/9362

[petemounce]

Published to chocolatey, apologies for delay.

[jmillikin-stripe]

https://github.com/bazelbuild/bazel/issues/9998 is an unexpected regression from v0.29, given that str.replace() is documented as taking a keyword parameter for maxsplit and major projects such as Kubernetes depend on the documented behavior.