Skip to content
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 3.6 - September 2020 #12040

Closed
10 tasks done
laurentlb opened this issue Sep 2, 2020 · 22 comments
Closed
10 tasks done

Release 3.6 - September 2020 #12040

laurentlb opened this issue Sep 2, 2020 · 22 comments
Assignees
Labels

Comments

@laurentlb
Copy link
Contributor

laurentlb commented Sep 2, 2020

Status of Bazel 3.6

To report a release-blocking bug, please file a bug using the Release blocker label, and cc me.

Task list:

@laurentlb
Copy link
Contributor Author

Bazel 3.6.0rc2 is now available for those that want to try it out.
https://releases.bazel.build/3.6.0/rc2/index.html

@keith
Copy link
Member

keith commented Sep 11, 2020

If possible I think we should cherry pick #12046 once it lands. Without it in sandboxed builds on darwin you get log spew for every static archive action:

external/local_config_cc/libtool: line 40: /private/var/tmp/_bazel_iosci/4988be46b65c576ca5906aacc315f576/sandbox/darwin-sandbox/333/execroot/lyftios/external/local_config_cc/libtool_check_unique: No such file or directory
external/local_config_cc/libtool: line 40: /private/var/tmp/_bazel_iosci/4988be46b65c576ca5906aacc315f576/sandbox/darwin-sandbox/375/execroot/lyftios/external/local_config_cc/libtool_check_unique: No such file or directory
external/local_config_cc/libtool: line 40: /private/var/tmp/_bazel_iosci/4988be46b65c576ca5906aacc315f576/sandbox/darwin-sandbox/376/execroot/lyftios/external/local_config_cc/libtool_check_unique: No such file or directory
external/local_config_cc/libtool: line 40: /private/var/tmp/_bazel_iosci/4988be46b65c576ca5906aacc315f576/sandbox/darwin-sandbox/381/execroot/lyftios/external/local_config_cc/libtool_check_unique: No such file or directory
external/local_config_cc/libtool: line 40: /private/var/tmp/_bazel_iosci/4988be46b65c576ca5906aacc315f576/sandbox/darwin-sandbox/378/execroot/lyftios/external/local_config_cc/libtool_check_unique: No such file or directory
external/local_config_cc/libtool: line 40: /private/var/tmp/_bazel_iosci/4988be46b65c576ca5906aacc315f576/sandbox/darwin-sandbox/438/execroot/lyftios/external/local_config_cc/libtool_check_unique: No such file or directory

@katre
Copy link
Member

katre commented Sep 11, 2020

My work to remove TransitionMode introduced some issues with Android builds: the symptoms are that android builds that set --fat_apk_cpu start seeing errors during one version checking (which appears to be in Bazel). To fix it, we need to cherrypick 1ae143b and 23b0b8a, which I think will apply clearly.

Also, #12069 was filed about a regression in 3.5, and could be fixed if we cherrypick 144d514 as well.

@meteorcloudy
Copy link
Member

b3ac8f6 and 26cbf77 was cherry picked for 3.5.1 for fixing #12056, we should probably cherry-pick for 3.6.0 as well.

@laurentlb
Copy link
Contributor Author

I'll create a new candidate with the cherrypicks on Monday (sorry for the delay, I'm on vacation this week).

@konste
Copy link

konste commented Sep 16, 2020

I just opened a bug #12117. Don't know if it is big enough to be considered a release blocker for 3.6.0, but on the other hand, it looks like a glaring omission and hopefully is easy to fix.

@trybka
Copy link
Contributor

trybka commented Sep 18, 2020

#12046 is in, and per @keith's comments, it would be good to cherry pick this.

@laurentlb
Copy link
Contributor Author

Cherrypick list so far: 1ae143b, 23b0b8a, 144d514, b3ac8f6, 26cbf77

#12117 doesn't seem critical and I haven't seen any fix for it.
I've added a comment to clarify #12046 (comment)

@laurentlb
Copy link
Contributor Author

Created 3.6.0rc3 using:
scripts/release/release.sh create --force_rc=3 3.6.0 aa0d97c 1ae143b 23b0b8a 144d514 b3ac8f6 26cbf77

https://releases.bazel.build/3.6.0/rc3/index.html

@laurentlb
Copy link
Contributor Author

Created 3.6.0rc4 using:

scripts/release/release.sh create --force_rc=4 3.6.0 aa0d97c 1ae143b 23b0b8a 144d514 b3ac8f6 26cbf77 8b29b6a

https://releases.bazel.build/3.6.0/rc4/index.html

@thii
Copy link
Member

thii commented Oct 3, 2020

May I request to cherry-pick abc2211? This is a long-standing bug that the only workaround was to uninstall python@2 from Homebrew, even though we're not using any Homebrew installed tools.

@laurentlb
Copy link
Contributor Author

Cherrypicks are usually for recent regressions (something that worked with the previous version of Bazel). Since we're already late with Bazel 3.6 (and Bazel 3.7 process is starting this week), I'd rather not add any delay.

@thii
Copy link
Member

thii commented Oct 5, 2020

Totally makes sense. We can wait for 3.7.

@laurentlb
Copy link
Contributor Author

@philwo
Copy link
Member

philwo commented Oct 6, 2020

Bazel 3.6.0 arm64 binaries uploaded to GitHub and https://releases.bazel.build/3.6.0/release/.

@vbatts
Copy link

vbatts commented Oct 6, 2020 via email

@vbatts
Copy link

vbatts commented Oct 6, 2020

@philwo can you share the full build flags used to invoke your arm64 builds? I'm wondering if it's memory issues or such, that cause all the aarch64 builds to fail on fedora and epel.

@philwo
Copy link
Member

philwo commented Oct 6, 2020

@vbatts Sure! This is the full script used to build the binaries. There aren't any special flags, except the --sandbox_tmpfs_path=/tmp due to #3236.

git fetch origin master
git fetch --force origin refs/notes/*:refs/notes/*
git checkout ${BUILDKITE_BRANCH}

release_name=$(buildkite-agent meta-data get "release_name")
echo "release_name = \"$release_name\""

bazel build --sandbox_tmpfs_path=/tmp //src:bazel
mkdir output
cp bazel-bin/src/bazel output/bazel

output/bazel build \
    -c opt \
    --stamp \
    --sandbox_tmpfs_path=/tmp \
    --embed_label "${release_name}" \
    --workspace_status_command=scripts/ci/build_status_command.sh \
    src/bazel

mkdir artifacts
cp "bazel-bin/src/bazel" "artifacts/bazel-\${release_name}-linux-arm64"

cd artifacts
buildkite-agent artifact upload "*"

It runs inside this Docker container (centos7-releaser): https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/docker/centos7/Dockerfile#L50

In order to get the initial bazel binary for the first Bazel release, I used the compile.sh bootstrap. I just tested that this still works on Ubuntu 18.04 and CentOS 7:

mkdir bazel-3.6.0
cd bazel-3.6.0
curl -O https://releases.bazel.build/3.6.0/release/bazel-3.6.0-dist.zip
unzip bazel-3.6.0-dist.zip
./compile.sh

which results in:

INFO: Elapsed time: 330.766s, Critical Path: 264.48s
INFO: 2457 processes: 49 internal, 1693 local, 715 worker.
INFO: Build completed successfully, 2457 total actions
Build successful! Binary is here: /bazel-3.6.0/output/bazel

Our arm64 machine is hosted by packet.net and described as an "Ampere® eMAG processor, which features 32 Arm cores operating at 3.3 GHz, with 128GB of RAM, 480GB of SSD storage and dual 10Gbps network ports" (though of course building Bazel should work on a smaller machine, too 😅).

@vbatts
Copy link

vbatts commented Oct 7, 2020

@philwo good info. I don't have direct access to the arm machines used on the copr.fedorainfracloud.org/ build-infra, but fired up a pine64 (2G ram/1G swap; 4 cores), and the ./compile.sh got the system load up to 56 and then it seized.
So maybe only beefy machines like the Ampere on Packet (Equinix Metal?) will work now?

@vbatts
Copy link

vbatts commented Oct 7, 2020

alrighty. I spun up a c1.large.arm on equinixmetal (on flatcar 🚋 ), ran a docker fedora:32 container, and in it:

dnf install -y rpm-build make xz git
git clone https://github.com/vbatts/copr-build-bazel
cd copr-build-bazel/
make rebuild # also 'make rpm' will work

And it successfully built the binary rpm in 570s or so. (/root/rpmbuild/RPMS/aarch64/bazel3-3.6.0-0.fc32.aarch64.rpm)

Given the cryptic failures I'm seeing on aarch64 on the copr.fedorainfracloud.org, it is my guess that their machines are too small, or that the bazel build is [too] demanding. (this c1.large.arm does have 96 cores/130G ram)

@meisterT meisterT reopened this Oct 14, 2020
@meisterT
Copy link
Member

We missed a cherry pick in 3.6.0, see #12086 (comment)

@laurentlb
Copy link
Contributor Author

Bazel 3.7 is out and should be used instead.

@katre katre unpinned this issue Oct 23, 2020
@philwo philwo pinned this issue Nov 11, 2020
@meisterT meisterT unpinned this issue Jan 21, 2021
@hochhaus hochhaus mentioned this issue Apr 25, 2021
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests