Upgrade to Bazel 5 (again) #17319
Upgrade to Bazel 5 (again) #17319
Conversation
|
bazelbuild/bazel#14848 is still a problem, not sure how to work around it |
|
let's see how bad it gets without |
|
hm, I was able to get past the |
akrmn
force-pushed
the
akrmn/bazel-5
branch
2 times, most recently
from
f6fa8dc to
940d2cb
Compare
.bazelrc
Outdated
| @@ -1,7 +1,7 @@ | |||
| # Bazel distributed cache, can be temporarily disabled by passing the following | |||
| # flag: --noremote_accept_cached | |||
| build:darwin --remote_http_cache=https://bazel-cache.da-ext.net | |||
| build:linux --remote_http_cache=https://bazel-cache.da-ext.net/ubuntu_20_04 | |||
| build:darwin --remote_cache=https://bazel-cache.da-ext.net/bump | |||
There was a problem hiding this comment.
If we're doing that please take the opportunity to clean this up a bit and go for something like /macos/202308 & /ubuntu/202308.
I'd really like if we could have some sort of shell escape in .bazelrc to make this /$(uname -s)/$(date -I | cut -c 1-7) or something. Last I checked the Bazel devs didn't believe in templating .bazelrc though.
There was a problem hiding this comment.
thanks for the suggestion, if it works with /bump I'll clean up as you described
There was a problem hiding this comment.
since this built on windows I'm confident it should also build on macos and linux, so I applied this change. for the windows cache, I removed my /bump and instead increased -v{13=>14} (the big comment in ci/configure-bazel.sh made me worry that a cleaner (but longer) suffix might break things on windows)
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
the linux build appeared to fail on |
|
Running out of time is definitely expected in a "blank cache" run. Timeout is controlled by the YAML files (linux, macos, windows), so one option is to increase them in this branch. Alternatively, subsequent builds should benefit from the cache, so "keep rerunning" should work. I've restarted the current build. |
akrmn
force-pushed
the
akrmn/bazel-5
branch
2 times, most recently
from
a72bddb to
8f3e5ed
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| patches = oldAttrs.patches ++ [ | ||
| # This should be upstreamed. Bazel is too aggressive | ||
| # in treating arguments starting with @ as response files. | ||
| ./bazel-cc-wrapper-response-file.patch |
There was a problem hiding this comment.
This fix has been upstreamed and is available from Bazel 5.1.0
bazelbuild/bazel@48b60d2
|
@garyverhaegen-da should we undo the timeout bump in this PR after the macOS build finishes? or do you think it's safer to do it in a separate PR after this is merged? |
akrmn
requested review from
filmackay,
remyhaemmerle-da,
basvangijzel-DA,
dylant-da,
samuel-williams-da,
paulbrauner-da and
gerolf-da
as code owners
I believe Windows uses a different cache for main branch builds, so it will probably be less painful to leave the expanded timeouts in this PR and remove them in a follow-up one. |
| build --java_language_version=11 | ||
| build --java_runtime_version=nixpkgs_java_11 | ||
| build --tool_java_runtime_version=nixpkgs_java_11 | ||
| build --tool_java_language_version=11 |
This reverts commit 6ae0e01.
This PR is based on @moritzkiefer-da's unmerged work in #12935 for upgrading to Bazel 5.