Add compatibility test to check that old Rust gencode works with newer runtime #23848
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![copybara-service[bot]](https://avatars.githubusercontent.com/in/44061?s=80&v=4){kind=small}
copybara-service
bot
force-pushed
the
test_816413950
branch
5 times, most recently
from
02b4b53 to
d177537
Compare
…r runtime This way this works is that we download our prebuilt protoc release binary and put simple `MODULE.bazel` and `BUILD.bazel` files in front of it so that it looks like a normal Bazel dependency. We can then run all our Cargo tests using that protoc binary to generate code. The nice thing about this approach is that it should require pretty minimal maintenance going forward. Since we're not building the old protoc from source, we don't have to worry about it bit-rotting and requiring new patches. Any time we add new tests, those will also get picked up immediately, as long as they are run with Cargo and not just Bazel. One drawback is that this only works for Linux on x86-64, but this seems fine since the compatibility we are trying to test is unlikely to be platform-specific. If and when we ever add bug fixes or new features that will not work with old gencode, we will need a way to exclude their tests from compatibility testing. I believe that should be easy to handle by just putting something like `#[cfg(not(compatibility_test))]` above the necessary test cases. Ordinarily our `protobuf_codegen` crate will refuse to allow any mismatch between the protoc version and runtime version, but I had to make an exception so that it would allow us to have a mismatch for testing purposes. If the `ALLOW_PROTOC_VERSION_MISMATCH` environment variable is set then the codegen crate will not enforce that the versions match. PiperOrigin-RevId: 816413950
copybara-service
bot
force-pushed
the
test_816413950
branch
from
d177537 to
a0a20f0
Compare
|
Auto-closing Copybara pull request |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add compatibility test to check that old Rust gencode works with newer runtime
This way this works is that we download our prebuilt protoc release binary and
put simple
MODULE.bazelandBUILD.bazelfiles in front of it so that itlooks like a normal Bazel dependency. We can then run all our Cargo tests using
that protoc binary to generate code.
The nice thing about this approach is that it should require pretty minimal
maintenance going forward. Since we're not building the old protoc from source,
we don't have to worry about it bit-rotting and requiring new patches. Any time
we add new tests, those will also get picked up immediately, as long as they
are run with Cargo and not just Bazel.
One drawback is that this only works for Linux on x86-64, but this seems fine
since the compatibility we are trying to test is unlikely to be
platform-specific.
If and when we ever add bug fixes or new features that will not work with old
gencode, we will need a way to exclude their tests from compatibility testing.
I believe that should be easy to handle by just putting something like
#[cfg(not(compatibility_test))]above the necessary test cases.Ordinarily our
protobuf_codegencrate will refuse to allow any mismatchbetween the protoc version and runtime version, but I had to make an exception
so that it would allow us to have a mismatch for testing purposes. If the
ALLOW_PROTOC_VERSION_MISMATCHenvironment variable is set then the codegencrate will not enforce that the versions match.