Release 0.25 - April 2019

[laurentlb]

Target RC date: April 1st

[dslomov]

We would like to get fixes for #6426 (/cc @aragos) and #7910 (/cc @buchgr) into 0.25. Let's make an ETA for a cut April 3rd - if the fixes are not available by then, we will cut anyway - ok with you @dkelmer ?

[dkelmer]

SGTM

I would also like to mention that the fix for #7773 should probably be in the release as the behavior is gated by an incompatible change flag so people that migrated post the 0.24 release where the flag became available will now be broken.

[dslomov]

Update #6426 is not making it :(

[buchgr]

Update #7910 has been fixed.

[dkelmer]

Great! The latest green of the Bazel@HEAD + Downstream is from before those commits so I will trigger a new run now and then cut from that

[dkelmer]

Waiting for this run to complete: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/898#c5fe1ee3-fbfb-4222-bcda-a6647b64e147

[dkelmer]

To create 0.25.0rc1!
scripts/release/release.sh create 0.25.0 03662462941953dad23af88693804b8b1d4430b9

[dkelmer]

Downstream test of rc1: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/901

[laszlocsomor]

Can I request a cherrypick to flip an incompatible flag (#7486)?

[laszlocsomor]

Can I request a cherrypick to flip an incompatible flag (#7486)?

If yes, please cherry-pick afeb8d0. Thanks!

[laszlocsomor]

Another potential cherry-pick:

• 0.25.0 will be a migration window for --incompatible_windows_native_test_wrapper (incompatible_windows_native_test_wrapper: enables Bash-less test execution on Windows #6622)
• I just found a bug in this feature (Windows: native test wrapper incorrectly escapes arguments [blocking #6622] #7956), that I can fix easily
• is it fine to cherry-pick this bugfix, so I don't have to guard the bugfix with another incompatible flag?

Related: https://groups.google.com/d/msg/bazel-dev/Q4wwSSmn_ao/Oh7ht3DaBAAJ

[dkelmer]

@laszlocsomor: Regarding #7486, did you run a "tgp" with the flag flip? Instructions here. If it's clean I'll cherry pick it.

And I will cherry pick the bug fix for #7956. Ping this issue when that is ready and I'll cherry pick both together (assuming the flag flip is clean-ish)

[laszlocsomor]

@dkelmer : Yes and it all passed, see #7646 (comment).

Great, I'll do as you asked. Thanks!

[laszlocsomor]

Merged fix for #7956. Please cherrypick 3f7f255.

[dkelmer]

To create 0.25rc2
scripts/release/release.sh create --force_rc=2 0.25.0 03662462941953dad23af88693804b8b1d4430b9 3f7f255f9a8345b8898e3953e7e53d68106cc63d afeb8d0b7fef619159fc8fbaaeb8bd41dd2619bd

[buchgr]

#8008 is a release blocker. I ll ping this thread once it's fixed.

[limdor]

Some findings of breaking changes in bazel 0.25 + cc_library + action_env + USERNAME variable, not enough information yet to open a proper bug:
https://groups.google.com/d/msg/bazel-dev/zotC5HGla8I/y3rgU8wjCwAJ

[buchgr]

#8008 has been fixed. Please cherry-pick 4299b65

[dkelmer]

Command to create rc3:
scripts/release/release.sh create --force_rc=3 0.25.0 03662462941953dad23af88693804b8b1d4430b9 3f7f255f9a8345b8898e3953e7e53d68106cc63d afeb8d0b7fef619159fc8fbaaeb8bd41dd2619bd 4299b6549cbc1b3e4494c91ed2f51d49b14c7980

[shahms]

In that I will have to manually downgrade to 0.24 because my employer pushes new releases of Bazel to workstations automatically, it's annoying but manageable ;-) Thanks for looking into it.

[vbatts]

fedora and centos builds are up.
Not a blocker, but build failed for rawhide with:

third_party/grpc/src/core/lib/gpr/log_linux.cc:43:13: error: ambiguating new declaration of 'long int gettid()'
   43 | static long gettid(void) { return syscall(__NR_gettid); }
      |             ^~~~~~
In file included from /usr/include/unistd.h:1170,
                 from third_party/grpc/src/core/lib/gpr/log_linux.cc:41:

That is with gcc 9.0.1-0.15.fc31

[vbatts]

https://copr.fedorainfracloud.org/coprs/vbatts/bazel/builds/ for more information. Specifically builder-live.log from https://copr-be.cloud.fedoraproject.org/results/vbatts/bazel/fedora-rawhide-x86_64/00902055-bazel/

[excitoon]

ScoopInstaller/Scoop#3433

[jin]

0.25 broke rules_scala. Same pipeline worked on 0.24.

https://buildkite.com/bazel/rules-jvm-external-examples/builds/259#f5b93b74-ed72-4217-b392-e339912a72a0

ERROR: /home/bazel/.cache/bazel/_bazel_bazel/600edb71338d22ba878d955ee9e0e953/external/io_bazel_rules_scala/third_party/unused_dependency_checker/src/main/BUILD:5:1: in scala_library_for_plugin_bootstrapping rule @io_bazel_rules_scala//third_party/unused_dependency_checker/src/main:unused_dependency_checker:
--
  | Traceback (most recent call last):
  | File "/home/bazel/.cache/bazel/_bazel_bazel/600edb71338d22ba878d955ee9e0e953/external/io_bazel_rules_scala/third_party/unused_dependency_checker/src/main/BUILD", line 5
  | scala_library_for_plugin_bootstrapping(name = 'unused_dependency_checker')
  | File "/home/bazel/.cache/bazel/_bazel_bazel/600edb71338d22ba878d955ee9e0e953/external/io_bazel_rules_scala/scala/private/rule_impls.bzl", line 769, in scala_library_for_plugin_bootstrapping_impl
  | _lib(ctx, scalac_provider.default_class..., <3 more arguments>)
  | File "/home/bazel/.cache/bazel/_bazel_bazel/600edb71338d22ba878d955ee9e0e953/external/io_bazel_rules_scala/scala/private/rule_impls.bzl", line 689, in _lib
  | _compile_or_empty(ctx, ctx.outputs.manifest, cjars, srcj..., <6 more arguments>)
  | File "/home/bazel/.cache/bazel/_bazel_bazel/600edb71338d22ba878d955ee9e0e953/external/io_bazel_rules_scala/scala/private/rule_impls.bzl", line 467, in _compile_or_empty
  | java_common.run_ijar(ctx.actions, jar = ctx.outputs.jar, <2 more arguments>)
  | expected value of type 'JavaToolchainSkylarkApiProvider' for parameter 'java_toolchain', for call to method run_ijar(actions, jar, target_label = None, java_toolchain) of 'java_common'

cc @iirina

[petemounce]

Published to chocolatey

[dkelmer]

@iirina can you take a look at #7498 (comment)? Though @jin, I'm a little surprised this is the case because it didn't show up in the test with downstream projects: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/939

[dkelmer]

Update on the 0.25 release: We're doing a patch release to address #8226. The fix will be to provide an implementation and the API that will be available in 0.26.

[laurentlb]

Did you send an announcement to the blog and bazel-discuss@?

[dkelmer]

@laurentlb, no. I can send an email to bazel-discuss@. What do you mean by sending an announcement to the blog?

[jin]

@dkelmer @iirina you can ignore #7498 (comment) - fixed by bumping rules_scala.

[dkelmer]

fix to #8236 also needs to be included in the patch release

[dkelmer]

Command to create 0.25.1rc3
scripts/release/release.sh create --force_rc=3 0.25.1 f44bc4732650f6ad011407cc5c41cb36de23acdb ed48a4a5fddbd93b057c3aa726e15720d79dcf8f 81aefe7ee01cc73646a53f9c72ed40ead09f9f5a

Note that first commit is the 0.25.0 release, the second is a local commit, and the 3rd is a public commit

[dkelmer]

Patch release 0.25.1 has been released https://github.com/bazelbuild/bazel/releases/tag/0.25.1

[petemounce]

Pushed to chocolatey.

[jin]

The Android emulator team recently pushed a new stable emulator release that removed some files that Bazel's Android SDK BUILD template looks for (emulator64-x86 and emulator64-arm). Because of this, all Bazel versions will fail when trying to test android_instrumentation_test targets or run android_device rules. The problem is that there is no way for users to download an older version of the emulator from Android Studio or the sdkmanager command line, so users who update their Android emulators will see this breakage with no workaround.

#8280

This affects all Bazel versions, and has already been cherry-picked into 0.26.0rc7. Can we cherry-pick the fix to 0.25 too? The fix is here: 85a5a2b

cc @meteorcloudy

[dkelmer]

This is an interesting case because it's not a Bazel breakage, but I do think that it makes sense for the most recent version of Bazel to be able to build an android_device so I'll create a patch release (we can't cherry pick PRs into an existing release). But to clarify: there's no way the emulator auto updates, right? And so is it not possible that some people will still have an older version of the emulator image? Once 85a5a2b is cherry picked, won't that mean that the patch release won't work with those older emulators?

[jin]

The emulator will not automatically update, but new SDK downloads will use the new emulator. The patch is also backwards compatible with older emulator versions.

[dkelmer]

Backwards compatible is what I wanted to hear ;)
Starting the patch release process now

[dkelmer]

Also adding the fix to #8254 to the patch release

[dkelmer]

To create 0.25.2:

scripts/release/release.sh create --force_rc=2 0.25.2 582b79ef3e2c9c9ae1878eedd2771df11c5f6061 0900660d67b53a56a13d1fa16a788e4cecbb1c0e 85a5a2bd569a5274950fc7327a044c395248c024

[buchgr]

The fix for this will require a patch release, as the bug effectively causes an an infinite loop for remote execution: #8320

[dkelmer]

Created 0.25.3
scripts/release/release.sh create 0.25.3 318aebb523b3c91275855e35f0a67814e0d2231f 0ff19c6d0adf3c0df94fff59ca3bd13cbcf99897

[petemounce]

I tried to create the 0.25.3 chocolatey package, but https://github.com/bazelbuild/bazel/releases/tag/0.25.3 does not exist yet?

[dkelmer]

@petemounce, that is correct. I'm pushing it now. There was an issue that has been resolved.