laurentlb commented 5 years ago

Target RC date: April 1st

dslomov commented 5 years ago

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 commented 5 years ago

SGTM

I would also like to mention that the fix for https://github.com/bazelbuild/bazel/issues/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 commented 5 years ago

Update #6426 is not making it :(

buchgr commented 5 years ago

Update #7910 has been fixed.

dkelmer commented 5 years ago

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 commented 5 years ago

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

dkelmer commented 5 years ago

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

dkelmer commented 5 years ago

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

laszlocsomor commented 5 years ago

Can I request a cherrypick to flip an incompatible flag (https://github.com/bazelbuild/bazel/issues/7486)?

laszlocsomor commented 5 years ago

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

If yes, please cherry-pick afeb8d0b7fef619159fc8fbaaeb8bd41dd2619bd. Thanks!

laszlocsomor commented 5 years ago

Another potential cherry-pick:

0.25.0 will be a migration window for --incompatible_windows_native_test_wrapper (https://github.com/bazelbuild/bazel/issues/6622)
I just found a bug in this feature (https://github.com/bazelbuild/bazel/issues/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?

dkelmer commented 5 years ago

@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 commented 5 years ago

@dkelmer : Yes and it all passed, see https://github.com/bazelbuild/bazel/pull/7646#issuecomment-480215177.

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

laszlocsomor commented 5 years ago

Merged fix for #7956. Please cherrypick https://github.com/bazelbuild/bazel/commit/3f7f255f9a8345b8898e3953e7e53d68106cc63d.

dkelmer commented 5 years ago

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

buchgr commented 5 years ago

https://github.com/bazelbuild/bazel/pull/8008 is a release blocker. I ll ping this thread once it's fixed.

limdor commented 5 years ago

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 commented 5 years ago

8008 has been fixed. Please cherry-pick 4299b6549cbc1b3e4494c91ed2f51d49b14c7980

dkelmer commented 5 years ago

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

dkelmer commented 5 years ago

@limdor Any update on the thread/bug?

limdor commented 5 years ago

For the moment I know that is related to: disk cache + cc_library + .a files + action_env=USERNAME + Bazel from 0.24 to 0.25 rc The problem is that I could still not get a minimum reproduceable. On Wednesday I will try again if I can get one.

On Mon, Apr 22, 2019, 19:46 Danna Kelmer notifications@github.com wrote:

@limdor https://github.com/limdor Any update on the thread/bug?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel/issues/7498#issuecomment-485490712, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXONNP7XXBI45QGFWUZUVLPRX2XFANCNFSM4GZBFFVQ .

limdor commented 5 years ago

@dkelmer I tried to reproduce it with a clean disk cache and I could not get a reproducible even with my original project. Unfortunately I didn't keep a copy of the cache to investigate deeper.

steeve commented 5 years ago

Hey guys, is it possible to cherry-pick https://github.com/bazelbuild/bazel/commit/0020a97fdc20ca099ec6386771b20d3236f9890d ?

Not a regression per se but Xcode 10.2 breaks without it.

meteorcloudy commented 5 years ago

@dkelmer We need to cherry-pick https://github.com/bazelbuild/bazel/commit/130f86ded1ce84f959f0b78c065211902faed546 to fix https://github.com/bazelbuild/bazel/issues/8104

dkelmer commented 5 years ago

scripts/release/release.sh create --force_rc=8 0.25.0 03662462941953dad23af88693804b8b1d4430b9 3f7f255f9a8345b8898e3953e7e53d68106cc63d afeb8d0b7fef619159fc8fbaaeb8bd41dd2619bd 4299b6549cbc1b3e4494c91ed2f51d49b14c7980 231270c67d5aa771462245531fa9b2ee7d3d0ae8 75a3a531b08e727ade4fa3cb0a574bd142727cce 4a6354a3a5ca23583f8b62e3e439a04ce75b863f ae102fbde3c1ff87e4f67007a275fb30792a4e8d 0020a97fdc20ca099ec6386771b20d3236f9890d 130f86ded1ce84f959f0b78c065211902faed546

Edit: that is the command I actually ran, but since 0020a97fdc20ca099ec6386771b20d3236f9890d was already in the baseline, it comes up as empty so instead use: scripts/release/release.sh create --force_rc=8 0.25.0 03662462941953dad23af88693804b8b1d4430b9 3f7f255f9a8345b8898e3953e7e53d68106cc63d afeb8d0b7fef619159fc8fbaaeb8bd41dd2619bd 4299b6549cbc1b3e4494c91ed2f51d49b14c7980 231270c67d5aa771462245531fa9b2ee7d3d0ae8 75a3a531b08e727ade4fa3cb0a574bd142727cce 4a6354a3a5ca23583f8b62e3e439a04ce75b863f ae102fbde3c1ff87e4f67007a275fb30792a4e8d 130f86ded1ce84f959f0b78c065211902faed546

dkelmer commented 5 years ago

@steeve @meteorcloudy, cherrypicking now

keith commented 5 years ago

@steeve @dkelmer that fix is already in 0.25?

dkelmer commented 5 years ago

@keith, you're right. Thanks for catching that. I think it doesn't matter that it will be listed as a cherry pick though so I will proceed with rc8 which has @meteorcloudy's cherry pick in it.

hlopko commented 5 years ago

It seems https://github.com/bazelbuild/bazel/issues/8104 was introduced in 0.23 (was it @meteorcloudy?), so it's not a 0.24 regression strictly speaking (if I remember the policy correctly :) Couldn't the fix wait for 0.26 which we're cutting this Thursday? Delaying 0.25 means we will not be able to test incompatible changes before 0.26 is cut.

dkelmer commented 5 years ago

@hlopko, Ah, sorry I didn't notice that and already pushed the RC. So question 1 would be: is it even possible to release an older RC? Even if it is, question 2 is: why do you need 0.25 to be out to test incompatible changes? I thought you could run a custom presubmit with your flags? I will note that I'm going to release on Wednesday morning NY time, so you would have a few hours to test with incompatible changes before 0.26 gets cut.

dkelmer commented 5 years ago

Release blocking: https://buganizer.corp.google.com/issues/131462201

hlopko commented 5 years ago

Wednesday is a public holiday in Germany :) I'm not concerned by any specific incompatible flag I have, rather about the team velocity and happy users. It is true that if there was a flag I cared about, I could test it manually. But in that case I cannot migrate downstream project proactively - because they still use 0.24, and my behavior is only in on 0.25.

When 0.25 is out, our users can start testing incompatible flags and report back if the migration is not possible or contains bugs. Then we have the option to extend the migration window and fix the issue in 0.26. Without this feedback we have to either flip the flag blind, or wait for multiple releases.

We also don't have time for users to try 0.25, report regressions, and for us to fix regressions before 0.26 is cut. This will result in more cherrypicks in 0.26, which can slow down 0.27 and so on :)

steeve commented 5 years ago

@steeve @dkelmer that fix is already in 0.25?

My bad, I though RCs were tagged too, and since I didn't see it in a tag I wrongly assumed it wasn't. I'm glad it is !

dkelmer commented 5 years ago

@hlopko I mostly agree with your points. It's definitely important for people to test a particular release before we cut a new one. But I think that ideally users would try out the RC and report regressions with the RC so that we can fix the current RC, as opposed to add cherrypicks to the next release. However I do realize that users tend to not do this and I don't know the solution to that.

In the case of this particular release, I don't think 24 hours would've made a big difference but I am sorry nonetheless that it will be so tight :(

Kernald commented 5 years ago

Just a small note on this 0.25.0 release: something is slightly off with the changelog.

--incompatible_disable_legacy_crosstool_fields has been flipped (#6861)

is repeated three times. The line just below the second occurrence seems incomplete:

shahms commented 5 years ago

It would appear as though this release removed previously working functionality in cc_common.compile/link without any replacement (not just an incompatible API). This breaks a chunk of tests for Kythe.

shahms commented 5 years ago

Because of this, 0.25 is incompatible with Kythe, full-stop. It's one thing to change an interface in a backwards-incompatible way and entirely different to remove the implementation entirely when doing so.

dkelmer commented 5 years ago

Hi @shahms, I'm cc'ing @hlopko who will be more informed. Do you have some examples of breakages to help narrow down the issue?

dkelmer commented 5 years ago

Bazel 0.25 is released. You can see it here: https://github.com/bazelbuild/bazel/releases

@vbatts, @petemounce, and @excitoon Would you be able to update the various package definitions? Thanks!!

shahms commented 5 years ago

https://github.com/bazelbuild/bazel/issues/8226 is a bug specifically about this issue, but essentially 976876d changed the cc_common.compile API in a backwards incompatible way (fine and expected) but also simply removed the old implementation of that API so that they previously working (if suboptimal) functions now just return None. This isn't something we can work around.

dkelmer commented 5 years ago

Thanks for narrowing it down and filing the bug. cc'ing @oquenchil who was the author of the cited change to weigh in on what to do. @shahms, is it a problem for you to hold off on upgrading to 0.25 until tomorrow when we figure out what to do about the change?

shahms commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

lukesampson/scoop#3433

jin commented 5 years ago

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 commented 5 years ago

Published to chocolatey

dkelmer commented 5 years ago

@iirina can you take a look at https://github.com/bazelbuild/bazel/issues/7498#issuecomment-489286392? 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 commented 5 years ago

Update on the 0.25 release: We're doing a patch release to address https://github.com/bazelbuild/bazel/issues/8226. The fix will be to provide an implementation and the API that will be available in 0.26.

laurentlb commented 5 years ago

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

bazelbuild / bazel

Release 0.25 - April 2019 #7498

8008 has been fixed. Please cherry-pick 4299b6549cbc1b3e4494c91ed2f51d49b14c7980