-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 0.27 - June 2019 #7816
Comments
I would like 84c5dc9#diff-73cc3e84377e7c63ef4406039e060016 (or an equivalent thereof) to be in this release. For my employer I started this fairly large migration to bazel seeing from documentation it did everything we needed, however, it seems pkg_deb does not have a templates parameter which we use quite heavily in our existing software meaning the resulting packages in the current state are kindof useless. I'm at a point of having to make a bazel build from master just for this one feature. Amazing tool otherwise, though! It's just this one thing is kindof a stickling point at the moment. |
It will definitely be included. Any change submitted in May will be included. Changes submitted in June are unlikely to part of 0.27. Thanks for the feedback! |
Cool, was checking because I got confused about the 0.26 release still not having it, guess I just unlucky about the way times line up then. In the meantime I'll use a custom build, but at least it's not long to wait. |
Status of Bazel 0.27I plan to keep this message up to date during the release process and provide the important information.
To report a release-blocking bug: file a bug, use the Task list:
|
I'm about to flip All known downstream breakages are summarized in this comment. Most breakages are because targets had been declaring themselves (perhaps by default) to be Python 3, even though they were really only compatible with Python 2. Previously they sometimes got ran under Python 2 anyway due to #4815, but this flag fixes that bug on every platform besides Windows. Migration usually consists of adding +cc Green Team sheriffs @vladmos and @laszlocsomor. |
Creating 0.27.0rc1 with:
|
0.26.0 / 0.27.0 is broken in IntelliJ when building java_plugin targets - bazelbuild/intellij#845 Please cherry-pick b0403a7 (if it's after baseline) |
Created 0.27rc2 with:
(this includes both b0403a7 and 8c3b3fb) You can download the release candidate here: https://releases.bazel.build/0.27.0/rc2/index.html |
Of the two release blockers I filed, one is fixed and the other has a pending CL. Both concern the ease of migrating to toolchains but do not affect CI. The already submitted one is 123c68d and can be cherrypicked now. Will post when the other is submitted. |
And the other one is 052167e. |
Laurent, this might require a cherry pick: #8539 |
As pointed out in discussion in the above issue, bad5a2b introduced very serious regression (and is included in 0.27rc2):
As the consequence, after the upgrade from 0.26 to 0.27rc2 wrong byte code is generated, when building with
On Bazel 0.26 the last command would correctly print Java 8 byte code major version:
As the consequence, after building Gerrit Code Review project with 0.27.rc2, the produced artifact cannot be run any more on Java 8 (all is fine on 0.26):
Can this be fixed, or at very least, can this disruptive change be documented in the release documentation? |
Please note that we finished the migration to Ubuntu 16.04 for release builds and all other pipelines on Bazel CI now. This means that 0.27.0rc3 and following versions will be built on Ubuntu 16.04 and will no longer compatible with Ubuntu 14.04. We will mention this in the release notes, too. |
@laurentlb 6ef6d87 fixes #8539 and should be cherry picked for backwards compatibility. |
rc3 created with:
Available here: https://releases.bazel.build/0.27.0/rc3/index.html |
Please cherry pick e2a626c for bazel-contrib/rules_jvm_external#165 and android/testing-samples#279 Thank you! |
rc4 created with:
#8564 (comment) was not included. Download rc4: https://releases.bazel.build/0.27.0/rc4/index.html |
Update on toolchain downstream breakages here. |
#8536 is now release-blocking as I decide how to address the gerrit breakage. The error mode only occurs when
This combination should be pretty rare. |
Published to chocolatey. |
i'm still having issues getting this built for fedora and centos. ERROR: /builddir/build/BUILD/bazel-0.27.0/src/BUILD:311:2: Executing genrule //src:embedded_tools_nojdk failed (Exit 127): bash failed: error executing command
(cd /tmp/bazel_P4UK5kXs/out/execroot/io_bazel && \
exec env - \
PATH=/builddir/.local/bin:/builddir/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin \
/bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; bazel-out/host/bin/src/create_embedded_tools "bazel-out/k8-opt/bin/src/embedded_tools_nojdk.zip" bazel-out/k8-opt/bin/src/embedded_tools_nojdk.params')
Execution platform: @bazel_tools//platforms:host_platform |
@vbatts Can you open a new issue and we'll debug there? Did you pass |
python detection issue: #8665 |
fedora, centos7 and rhel8 rpms pushed. |
@laurentlb is there going to be a patch release? d458963 should be cherry picked (fixes #8670 which is a regression in bazel 0.27). |
I did all required changes to fix #8652 now. If a patch release for 0.27.0 is created, it will automatically be built on CentOS 7, which will fix the linked issue and restore compatibility with Ubuntu 14.04, CentOS 7 and RHEL 7. |
Cool cool to see official rpms. We'll see how well they work for Fedora. I'm glad to offload that from my copr.
As for transitioning the thousands of subscribers to my builds:
* Are you going to make a yum repo for these centos rpms?
* Is this a beta build for now?
* Is there going to be an announcement? (With transition steps for users)
…-------- Original Message --------
On Jun 25, 2019, 10:08, Philipp Wollermann wrote:
I did all required changes to fix [#8652](#8652) now. If a patch release for 0.27.0 is created, it will automatically be built on CentOS 7, which will fix the linked issue and restore compatibility with Ubuntu 14.04, CentOS 7 and RHEL 7.
—
You are receiving this because you were mentioned.
Reply to this email directly, [view it on GitHub](#7816?email_source=notifications&email_token=AAAQL2LWK6LNPUV2NW46ZJTP4IRHLA5CNFSM4HAO36LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYQLWEQ#issuecomment-505461522), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AAAQL2NEPCJ3YQW2SWBFCP3P4IRHLANCNFSM4HAO36LA).
|
@vbatts For this change, I just did the work on Bazel to pass its test suite on CentOS 7 (required a few small patches due to e.g. an older Git version in CentOS 7) and create a Docker container for our CI that contains what we need to build and test Bazel. Then I added CentOS 7 as a supported platform to our CI and changed our scripts to build the "default" Linux binaries on it. I verified that when using these binaries built on CentOS 7, our downstream pipeline still passes (even when you use these binaries on e.g. Ubuntu 18.04). I didn't expect any issues here, but wanted to make sure. That means, all official releases of Bazel will now have their Linux binaries built on CentOS 7 (instead of Ubuntu 16.04). This restores compatibility with Ubuntu 14.04, CentOS 7, while also staying compatible with newer Linux versions. As they should otherwise be functionally identical and pass all of our downstream tests, I'd consider them production ready. It would be nice to create official RPMs and setup a yum mirror, but that's a next step - as much as I personally like working with CentOS and Fedora, I really don't know anything about how to build good packages for it. :) I'm happy to look at your COPR packages and give it a try though and get your feedback to make sure that it looks good. |
@philwo ah okay. so the *.zip of binaries is good to go for those folks. Then I will keep rolling with the copr builds for now. If you were to make rpms and a yum(dnf) repo, copr is about as handy as anything. It does purge older builds, but if you're tagging releases, then folks can rebuild something about as equivalent. There is some automation to automatically trigger builds, but I haven't taken the time to iron that out. For now I mainly bump the version in the bazel.spec file and run Once bazel gets aarch64 build support, I can flip the switch to enable build chroots for all fedora's and centos/rhel (7 and 8). |
@laurentlb Gentle ping on @iirina's comment above: will there be a patch release? rules_go coverage tests are failing in CI with 0.27.0, and d458963 should fix it. We don't have a workaround for this issue at the moment. |
Bazel 0.27.1rc1 is available here: https://releases.bazel.build/0.27.1/rc1/index.html It was created with: So it's a cherry-pick of Irina's commit. |
Dear users, please also verify that Bazel 0.27.1rc1 restores compatibility with Ubuntu 14.04 and CentOS 7. |
I've verified 0.27.1rc1 fixes #8670 (bazel-contrib/rules_go#2100), both locally and on CI (log). Thanks! |
0.27.1 was released. |
* Revert "Work around for bazel 0.27.0 issue" This reverts commit 41bf7ea. Bazel 0.27.1 is out: bazelbuild/bazel#7816 (comment) * Trigger CI Signed-off-by: Taiki Ono <taiki@tetrate.io>
Created 0.27.2rc1 using The binary is available here: https://releases.bazel.build/0.27.2/rc1/index.html |
Target RC date: June 3rd
The text was updated successfully, but these errors were encountered: