While I was at it, I upgraded the previous release to 29.0.
`PROTOBUF_PREVIOUS_RELEASE` is not currently getting updated, and I deleted it
because I don't see an obvious way of referring to it from `MODULE.bazel`.
Hopefully soon we can drop it from `WORKSPACE` and then the only place to
update will be `MODULE.bazel`.
PiperOrigin-RevId: 743211189
We depend on protobuf v25 for the purpose of compatibility tests. Ideally we
would get v25 directly from BCR, but as far as I can tell there is no easy way
to get multiple versions of protobuf from BCR in the same bzlmod build. There
is
[multiple_version_override](https://bazel.build/rules/lib/globals/module#multiple_version_override),
but this seems to be geared toward resolving diamond dependency issues and not
so much toward deliberately testing against multiple versions.
This change therefore takes a different approach and uses
[archive_override](https://bazel.build/rules/lib/globals/module#archive_override).
I copied the necessary
[patches](https://github.com/bazelbuild/bazel-central-registry/tree/main/modules/protobuf/25.6/patches)
from BCR to get the code working with bzlmod. I also slightly tweaked the first
and last patches to give the module the name we want
(`com_google_protobuf_v25`).
I noticed that the v25 commit we depend on is not actually v25.0, but is v25.6
with a few additional fixes, so I updated our build to actually use v25.0.
PiperOrigin-RevId: 742781509
This required downgrading our use of the ads API, which we use only for
benchmarking. The most recent googleads version on BCR only supports v18, and
we can't easily use this one because it requires Bazel 7.2.1 or higher. So
instead we need to use an earlier version that only includes v17. I think this
is fine, though, because the v17 API is still supported and it should be easy
to upgrade once we have upgraded our Bazel version.
PiperOrigin-RevId: 741659742
A side effect of this was that we upgraded our Lua version from 5.2.4 up to
5.4.6. Version 5.3
[introduced](https://www.lua.org/manual/5.3/readme.html#changes)
support for integers as their own type, which broke some of our unit tests. We
have a shim of `lua_isinteger()` that always returns false for Lua versions
prior to 5.3, but starting from 5.3 we have the real version of that function
starting to return true for integers. In this scenario we were not validating
that the integer was in the expected range, so I had to fix this to keep the
tests green.
PiperOrigin-RevId: 741575531
Enables bzlmod for most CI tests, except python (and thus upb) since infra for system python headers for python dist are not bzlmod compatible and require further work.
#test-continuous
PiperOrigin-RevId: 721946253
This should silence the DEBUG warning
```
DEBUG: Rule 'com_google_protobuf_v25.0' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-e+7ZxRHWMs/3wirACU3Xcg5VAVMDnV2n4Fm8zrSIR0o="
```
PiperOrigin-RevId: 714142857
3.x.x descriptor.proto generated code is *not* supported with 4.x.x runtime, since this results in an ODR violation with the descriptor.proto built into the 4.x.x runtime. This is expected to result in undefined behavior / failures.
Tested against //java/core:v25_generated_message_test_jar (binary compatibility) and //java/core:v25_generated_message_test_srcjar (source compatibility)
PiperOrigin-RevId: 666329342
Adds new tests in `//compatibility` for detecting undesired breaking changes in the schema of the well-known types and `descriptor.proto` files, using the Buf breaking change detector, via [`rules_buf`](https://github.com/bufbuild/rules_buf/).
In order to keep things light-touch as far as maintenance goes, I have chosen to keep the integration as small and simple as possible. Some notes:
- Breaking change behavior can be granularly controlled via [`buf.yaml`](https://buf.build/docs/configuration/v1/buf-yaml#breaking).
- Bazel sandboxes us away from meaningful VCS information, so in order to pick a target to check for breaking changes against, a new variable is added to `protobuf_versions.bzl` that needs to be updated with changes in the release version.
- Breaking change detection is performed on a file-level, not a package-level, so migrating types across WKT files would constitute a breaking change. If this is not desired the behavior can be made to work on a package-level, though we need to do some more work as `buf_breaking_test` currently only accepts a single file descriptor set target for the `against` attribute.
Closes#17513
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17513 from jchadwick-buf:buf-breaking cd46bb2c1e
PiperOrigin-RevId: 658624708
Create WORKSPACE.bzlmod. Before building with Bzlmod resulted in use of full WORKSPACE.
Some repos are still there, but the file should eventually be empty.
Add dep to rules_kotlin 1.9.0. This was the first version available on BCR. It pushed upgrade of
rules_jvm_external to 6.0 and rules_java to 6.5.2 (keep 6.0.0 on Bazel 6.3.0).
Add missing maven and other deps to MODULE.bazel
CI changes:
Disable Bazel 6.4.0 with bzlmod. rules_jvm_external 6.0 use use_repo_rule, which is not supported by Bazel 6.
Add C++ build "Bazel7 with Bzlmod" enabled.
Add Java builds with "Bazel 7 with/without Bzlmod".
Fixes: https://github.com/protocolbuffers/protobuf/issues/17176
PiperOrigin-RevId: 652773197
