Bazel Rolling Releases

[philwo]

This is a tracking bug for Bazel Rolling Releases, similar to how we have individual release bugs for normal releases.

While I do the last preparations for rolling releases, I will track the commits made, commands run and overall progress here.

[konste]

May I please request cherry-pick pretty safe 2f0927a for the next rolling release?

[shirchen]

Is it possible to get a patch for 4.1 with #13521 which fixes #13512 ?

[wrowe]

Please pick 42e05db for the next 4.x.y release, which is needed by very complex projects with specific length test binary path names on Windows when grpc or abesil attempt to load symbols for diagnostics. Unfortunately it's the full path, so simply changing --output_base shifts the problem to tests with other filenames, and from one build machine to another that base root path tends to change length too

[philwo]

@konste @shirchen @wrowe I've added your cherry-pick requests to the Bazel 4.2.0 release tracking bug: #13558

Bazel rolling releases are always cut from the master branch close to HEAD and thus we do not do cherry-picks for those releases.

[fweikert]

Note: we started publishing rolling releases. The current one is https://github.com/bazelbuild/bazel/releases/tag/5.0.0-pre.20210604.6

[cpsauer]

Awesome!

Could I ask what the plan is for how rolling releases will interact with the other official Bazel rule extensions, like, for example, build_bazel_rules_apple? (If it's already out there and I've missed it, my apologies.)

[keith]

I think theoretically the hope is that rules maintainers support multiple versions of their rules that support the LTS releases. Speaking as a rules_apple maintainer I'm not sure yet if that will be feasible for us to support given the massive divergence between google's upstream apple rules, the rules_apple (and friends) repo, and the differences in bazel core that they depend on.

The current state is that the apple rules are community maintained, but google still pushes to an upstream branch as a reference, then the open source maintainers decide if we want to cherry pick those changes. The problem is that google's changes are only compatible with bazel HEAD, so cherry picking them could break compatibility with previous releases, but at the same time not taking them could mean we have to find other solutions to problems with Xcode compatibility (or other bug fixes). We're still discussing between maintainers what we should do here.

[cpsauer]

Thanks, Keith. Hear you loud and clear on the pain of LTS support vs rolling, and I super appreciate all you do to make rules_apple great.

I guess the follow on question is about how things will be handled in the rolling release world.
(The implicit goal being: having rules to run alongside the rolling Bazel releases.)

My understanding is that these rolling releases are in sync with Blaze CI--and the result of CI jobs from Bazel HEAD.
Does this mean, then, that there's a corresponding commit in, say, rules_apple upstream, compatible with Bazel HEAD at the time of the Bazel rolling CI job, which would be the right one to use with the rolling release?

[Capturing my uncertainties: Maybe that's what's already tagged as the rules_apple release--or they're already marked some other way? upstream was new to me, after all. Or maybe upstream and main have diverged sufficiently that we wouldn't want to use a commit from upstream, anyway? Or upstream works with blaze but not bazel, causing the divergence in the first place?]

More succinctly: Are rules planning to have a release track targeting Bazel rolling releases? What would you recommend users do who are excited to get new fixes/features more quickly and incrementally but still need a solid base?

[keith]

The only way we track this today is by putting in the release notes what versions of bazel things were tested with, so I think we'd have to keep that up

[sluongng]

Hi folks,

Rolling release bazel 5.0.0-pre.20210623.2 is breaking our bazel coverage //... runs because the test rules like buildifier_test (https://github.com/bazelbuild/buildtools/blob/master/buildifier/def.bzl#L12) and container_test (https://github.com/bazelbuild/rules_docker/blob/master/contrib/test.bzl#L125) does not provide coverage.dat

When changed .bazeliskrc with

--- a/.bazeliskrc
+++ b/.bazeliskrc
@@ -1,2 +1,2 @@
+USE_BAZEL_VERSION=4.1.0
-USE_BAZEL_VERSION=rolling

Then bazel coverage //... works again.

Here is a sample error message found when run on rolling release:

# Sample failing build target
load("@com_github_bazelbuild_buildtools//buildifier:def.bzl", "buildifier_test")

buildifier_test(
    name = "check_starlark_format",
    srcs = ["//:starlark_files"],
    lint_mode = "warn",
    mode = "diff",
)

filegroup(
    name = "starlark_files",
    srcs = glob(
        [
            "**/*.BUILD",
            "**/*.bzl",
            "**/*.sky",
            "**/BUILD",
            "**/BUILD.*.bazel",
            "**/BUILD.*.oss",
            "**/BUILD.bazel",
            "**/WORKSPACE",
            "**/WORKSPACE.*.bazel",
            "**/WORKSPACE.*.oss",
            "**/WORKSPACE.bazel",
            "*.BUILD",
            "*.bzl",
            "*.sky",
            "BUILD.*.bazel",
            "BUILD.*.oss",
            "WORKSPACE.*.bazel",
            "WORKSPACE.*.oss",
        ],
        exclude = [
            "bazel-*/**",
            ".git/**",
        ],
    ),
)

# sample error

ERROR: /home/sluongng/my/repo/BUILD.bazel:32:16: output 'check_starlark_format/coverage.dat' was not created
ERROR: /home/sluongng/my/repo/BUILD.bazel:32:16: Testing //:check_starlark_format failed: not all outputs were created or valid

[meisterT]

Hi @sluongng, I suggest to create a separate issue for this problem that can triaged properly to the right team.

[sluongng]

Hi @sluongng, I suggest to create a separate issue for this problem that can triaged properly to the right team.

@meisterT hmm in the top post it's said This is a tracking bug for Bazel Rolling Releases so I thought we reporting everything here. But ok let me create new issue.

[fweikert]

I'm closing this issue since the release process creates an individual tracking issue for each rolling release (e.g. #14582).