Bazel: Release - May 2018 - Target RC date: 2018-05-04 - name: 0.14.0

Created on 19 Apr 2018  路  71Comments  路  Source: bazelbuild/bazel

release

Most helpful comment

I've created 0.14.0rc1 with baseline 5c3f5c9be7fa40d4fb3c35756891fab8483ca406 and cherrypicked f96f037f8f77335dc444844abcc31a372a3e1849. The tests are running in https://buildkite.com/bazel/release/builds/40.

All 71 comments

@lfpino lmk if you are not available on these dates

@dslomov I believe the title of this issue and #5057, #5058, and #5059 erroneously says "2019" instead of "2018".

Thanks! Fixed.

@dslomov, which dates exactly? I will be on vacation from Apr 27 until May 2 (inclusive), so from the issue title I won't be available.

@lfpino we can change a date to May 3rd (which means you have to work on release the first day after your vacation), or you can swap with someone - see #5057, #5058 for some candidates :)

@lfpino Is there an approximate timeline for this release? Just wondering whether this will be pushed back to late May due to the delay in the 0.12/13 releases.

Hello Robin, sorry for the delay. I'm working on creating a new Release candidate (we should have one today or on Monday). On the other hand, the release itself should happen late May. Hope it helps.

I've created 0.14.0rc1 with baseline 5c3f5c9be7fa40d4fb3c35756891fab8483ca406 and cherrypicked f96f037f8f77335dc444844abcc31a372a3e1849. The tests are running in https://buildkite.com/bazel/release/builds/40.

The rules_scala failures (https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/233#cb39f107-6399-474f-92f3-e2a0fae08630) are tracked in https://github.com/bazelbuild/rules_scala/issues/498

The Windows related failures are tracked in https://github.com/bazelbuild/bazel/issues/5125.

The failures in rules_python seem to be unrelated to Bazel since the test is failing with 0.12 and 0.13 too, I've reported them there: https://github.com/bazelbuild/rules_python/issues/98

If we create another rc, can be please also cherry-pick ff8162d01409db34893de98bd840a51c5f13e257 to keep FreeBSD a known platform? Thanks.

Klaus, we don't need to. The shell toolchain is not yet in use.
In fact, I just learned from @gregestren that leaving the exec_compatible_with list empty makes the toolchain compatible with everything -- I'll update the documentation about that.

Klaus, we don't need to. The shell toolchain is not yet in use.

We still need the cherry-pick (or I have to locally patch it in the port); even if the shell toolchain is not yet used, sh_configure.bzl is still executed and fails the build with "Unknown OS".

In that case, would you accept waiting for a patch that removes the exec_compatible_with altogether, and cherrypicking that instead?

@aehlig : Before I start working on such a patch, could you please try if you can bootstrap on FreeBSD if you remove the exec_compatible_with altogether?

could you please try if you can bootstrap on FreeBSD if you remove the exec_compatible_with altogether?

@laszlocsomor I can confirm that using the following patch instead of ff8162d01409db34893de98bd840a51c5f13e257 also allows to bootstrap a working bazel on FreeBSD

--- tools/sh/sh_configure.bzl.orig      1980-01-01 00:00:00.000000000 +0000
+++ tools/sh/sh_configure.bzl   2018-05-16 09:37:28.256787000 +0000
@@ -49,16 +49,6 @@
   if sh_path and _is_windows(repository_ctx):
     sh_path = sh_path.replace("\\", "/")

-  os_label = None
-  if _is_windows(repository_ctx):
-    os_label = "@bazel_tools//platforms:windows"
-  elif repository_ctx.os.name.startswith("linux"):
-    os_label = "@bazel_tools//platforms:linux"
-  elif repository_ctx.os.name.startswith("mac"):
-    os_label = "@bazel_tools//platforms:osx"
-  else:
-    fail("Unknown OS")
-
   repository_ctx.file("BUILD", """
 load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain")

@@ -70,14 +60,10 @@

 toolchain(
     name = "local_sh_toolchain",
-    exec_compatible_with = [
-        "@bazel_tools//platforms:x86_64",
-        "{os_label}",
-    ],
     toolchain = ":local_sh",
     toolchain_type = "@bazel_tools//tools/sh:toolchain_type",
 )
-""".format(sh_path = sh_path, os_label = os_label))
+""".format(sh_path = sh_path))

 sh_config = repository_rule(
     environ = [

--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

@aehlig : Thank you! Would you mind creating a PR for this patch and requesting to cherrypick that?

@aehlig : Thank you! Would you mind creating a PR for this patch and requesting to cherrypick that?

That, as a change against bazel head, would be https://bazel-review.googlesource.com/c/bazel/+/56270

But note that this change is on top of ff8162d01409db34893de98bd840a51c5f13e257 so cannot be cleanly cherry-picked without that change as an earlier cherry-pick. Or did you mean a patch against the release branch?

--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

No, I meant a standalone patch based directly on master, and cherry-picking that into the release branch.
I just created it: https://github.com/bazelbuild/bazel/pull/5210

I'd like to request a cherry pick for the fix for #5133. This issue describes a regression with remote execution starting with 0.13.0. In a nutshell, before 0.13.0, remote execution users were able to run Bazel from a host that did not include a C compiler, but a hard restriction was introduced with 0.13.0 that makes any builds (including remote builds) fail if no C compiler is locally present. Its important to cherry pick the fix (which I think is almost submitted) as current remote execution customers are not able to use any versions after 0.12.0 at the moment. Thanks!

Thanks Nick! Can you (or @mhlopko) please let me know which commit once it's submitted?

@lfpino: Pretty please cherry pick https://github.com/bazelbuild/bazel/commit/57bc201346e61c62a921c1cbf32ad24f185c10c9 (a fix for #5133 which @nlopezgi mentioned 2 comments above). Gracias!

Created a new release candidate with BASELINE 5c3f5c9 and CHERRYPICKS f96f037 ff8162d 7092ed3 57bc201.

Currently building at: https://buildkite.com/bazel/release/builds/42

The only failures are:
rules_python: Not a change in Bazel, tracked in https://github.com/bazelbuild/rules_python/issues/98
rules_scala: tracked in https://github.com/bazelbuild/rules_scala/issues/498

For the rest we're green :-)

I still would consider #5202 a release blocker.

I have a proof-of-concept fix which I still have to test and clean up a bit.

https://bazel-review.googlesource.com/c/bazel/+/56490

--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

The RC2 announcement contains bad release notes: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/bazel-discuss/_VILqi8q9Co/XKLIbJRoCQAJ

Important changes:
...

  • Args objects (ctx.actions.args()) have new methods add_all() and
    add_joined() for building command lines using depsets.
    RELNOTES[INC]: Added flag
    --incompatible_disallow_old_style_args_add to help migrate from
    args.add() to args.add_all() / args.add_joined() where
    appropriate.

Please cherry-pick 35a78c09cf2fbfc3de9c124d2142e3d72aac4348

@buchgr can you please elaborate? I have no context for cherrypicking that commit.

@buchgr friendly ping.

It breaks remote caching users. If some files could not be downloaded completely, the build just fails and can't continue without a bazel clean.

Got it, will cherry-pick. Do we have any tests that are failing and should be part of "downstream projects" ? Namely, is there a way we can catch this in our CI?

no we unfortunately don't, but should.

Please also cherry-pick 3c9cd82b847f3ece8ec04b2029bd5e8ad0eb7502 which fixes #5202, i.e., that patch allows again that bazel can be built offline from the distribution archive.

Will do, I'm creating a new candidate with the additional two cherrypicks 35a78c0 3c9cd82

Created rc3 with BASELINE 5c3f5c9 and CHERRYPICKS f96f037 ff8162d 7092ed3 57bc201 35a78c0 3c9cd82

Currently building at: https://buildkite.com/bazel/release/builds/46

Please cherrypick 1b333a2c37add9d04fe5bc5258ee4f73c93115e2 and 3da8929963e9c70dff5d8859d6e988e6e7f4f9d7.

1b333a2c37add9d04fe5bc5258ee4f73c93115e2 fixes #5142 and 3da8929963e9c70dff5d8859d6e988e6e7f4f9d7 fixes #4750. These were two regressions introduced in 0.13.0 due to 0f5679ef95611e457a6e39313cf88feac8b2278f, which we can't roll back as we've made further changes that depend on that change.

Created rc4 with BASELINE 5c3f5c9 and CHERRYPICKS f96f037 ff8162d 7092ed3 57bc201 35a78c0 3c9cd82 27487c77387e457df18be3b6833697096d074eab 1b333a2 3da8929.

Built at: https://buildkite.com/bazel/release/builds/47

The bazel-toolchains failures seem to be infrastructure failures in Bazel CI, tracking in https://github.com/bazelbuild/bazel/issues/5267

The rules_python failures are still tracked in bazelbuild/rules_python#98

All the rest is green.

It's all green now (except for rules_python): https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/254

We should be able to release next Wednesday.

Can we cherry-pick https://github.com/bazelbuild/bazel/pull/5156/commits/bd7db6aa9283852b1c6cb2cf44931839d7bdcd39? This is a fix for regression from: https://github.com/bazelbuild/bazel/commit/88a007244f51ed66a62d442e28de483e13a68576 in 0.13.0 and 0.13.1 and Error Prone integration is broken, see #5134 and #5278.

Hi @davido I've confirmed with @iirina that this is a regression. I'll create another candidate.

@lfpino - that commit is not merged yet. It's waiting for @buchgr to review.

Link to pull request: #5156

Catching up - published 0.14.0-rc1 through rc4.

Thanks for the merge @buchgr I'll create a new candidate (rc5) with the additional cherrypick eca7b81cf8cc51e1fe56e5ed7d4ad5cd1668a17a

All looks green. We should be able to release release-0.14.0rc5 on Wednesday.

I didn't manage to get to this today. The release will happen on Friday. Sorry for the delay.

Pushed release:
https://github.com/bazelbuild/bazel/releases/tag/0.14.0
https://releases.bazel.build/0.14.0/release/index.html

@petemounce : Could you please update Chocolatey? Thanks!
@ilovezfs : Could you please update Homebrew? Thanks!

Thank you @ilovezfs !

You're welcome. 0.14.0 shipped in Homebrew.

Given that 0.14 is affected by https://github.com/bazelbuild/bazel/issues/5336 and it's a pretty serious issue, essentially making Bazel potentially unusable on machines where Docker isn't in a good shape (and running docker info on every build is questionable at best anyway), I propose that we do a patch release with that change included. @lfpino , what do you think?

+1 to patch release

I'll create a patch release tomorrow.

@lfpino could I ask for the patch release to include https://github.com/bazelbuild/bazel/pull/5338 also? Changes to the disk cache flags from 0.13->0.14 caused a regression in how remote execution flags are validated.

Hmm does #5308 warrant a patch release?

Since #5308 is not resolved yet, I suggets we create a 0.14.1 with just a fix for #5336

@dslomov, it's not resolved yet because you didn't import the patch yet. I just sent you the import.

@ulfjack I know but there is also a discussion on #5308 on whether that is the right fix.

I replied on the bug - I think we should merge the currently proposed fix, and cherrypick it.

@alexeagle from Angular is reporting memory regressions with 0.14.1: https://groups.google.com/d/msg/bazel-discuss/SOHd4FWX-6Q/rX7-3uQ5BAAJ

We should investigate and potentially roll out a 0.14.2 patch release.

@dslomov can you please take a look since you handled 0.14.1?

Was this page helpful?
0 / 5 - 0 ratings