Release - June 2018- Target RC date: 2018-06-04 - name: 0.15.0

[dslomov]

No description provided.

[dslomov]

@laurentlb lmk if you are not available on these dates

[laurentlb]

We have a RC for Bazel 0.15: https://groups.google.com/forum/#!topic/bazel-discuss/v4f-wMyLyOo

These projects are failing (https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/287):

• Bazel Remote Execution. Also failing with latest release. See bazel/remote-execution is broken #5323
• rules_python. See boto_test broken on mac rules_python#98
• TensorFlow Serving (ubuntu 14.04 & 16.04). See Bazel CI failing since PR #902 tensorflow/serving#911

[aehlig]

#5329 is a duplicate of #5323 but the latter is not yet fixed. Mentioning to keep track of the blocking issues.

[petemounce]

rc1 is on chocolatey.

[dslomov]

#5336 is a release blocker, let's cherry-pick 4b80f24

[dslomov]

Two more cherrypicks, the same that went into 0.14.1 (#5340):

• 4b80f24
• 6b16352

[laurentlb]

rc2 with the two cherrypicks: https://releases.bazel.build/0.15.0/rc2/index.html

[dslomov]

How about 4ec0a75? It fixes a regression introduced in 0.14.

[laurentlb]

rc3 was created 7 days ago: https://releases.bazel.build/0.15.0/rc3/index.html
It includes the 3 cherry-picks requested in this thread.

[RNabel]

The release notes state: The --experimental_remote_spawn_cache flag is now enabled by default. If this flag is experimental, why is it enabled by default? Are there any more docs on what the impact of this flag are?

[laurentlb]

This comes from this commit: cdf118a

@buchgr Can you clarify this? It would be nice to provide more context in the release announcement (https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit).

Thanks!

[buchgr]

@RNabel

I can now see that the wording is unfortunate. We graduated the flag to non-experimental by enabling it by default. It's in fact now a no-op, when using the remote cache. We kept it in for the 0.15.0 in order to not break any builds.

[buchgr]

released! @vbatts @petemounce @ilovezfs

[ilovezfs]

Homebrew/homebrew-core#29447

[ilovezfs]

0.15.0 shipped in Homebrew.

[vbatts]

fedora and centos build is kicked off https://copr.fedorainfracloud.org/coprs/vbatts/bazel/build/771133/
Also, I recently started stripping the binary, but was having issues isolating just the debug info from the binary so that could be available for folks interested. Not sure the issue there. But for now, the centos and fedora builds are stripped to 1.5Mb from their 100.5Mb original size :-)

[buchgr]

@vbatts tell me more? how did you accomplish this? [email protected]

[vbatts]

email sent

…

On 06/26/2018 11:01 AM, Jakob Buchgraber wrote: @vbatts <https://github.com/vbatts> tell me more? how did you accomplish this? ***@***.*** ***@***.***> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5057 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEF6VwNkRPDs3jlIwxZhJKgJ9Fadugwks5uAkzOgaJpZM4Tbu5n>.

[evantorrie]

@vbatts Did you test the resulting build?
After installing the stripped versions from vbatts/bazel (including 0.14.1-2), I get the following error on Fedora 28

[evant@learncollege-dl envoy]$ bazel
file is invalid or corrupted (missing end of central directory record)
Cannot find central directory
FATAL: Failed to open Bazel as a zip file: (error: 5): Input/output error

I'm pretty sure the stripping is stripping out the packaged internal binary

[petemounce]

Chocolatey is pushed.

[vbatts]

@evantorrie I see that. I must have not hit that on the 0.14.1-1 -> 0.14.1-2 upgrade locally because the extracted cache seemed fresh? not sure.
I have an updated/fixed build in the works for 0.15.0 https://copr.fedorainfracloud.org/coprs/vbatts/bazel/build/771662/

[dslomov]

0.15.0 is done, closing this.