We need this type to be trivial and standard layout because we directly read
its contents in Rust. This change removes its user-defined constructors so that
it becomes a trivial type.
PiperOrigin-RevId: 670572557
This ensures the names of these jobs will properly be prefixed with "[SKIPPED] (Continuous)" and will show as passed instead of skipped.
PiperOrigin-RevId: 666918220
Putting it into BUILD files unintentionally forces it on all our downstream users. Instead, we just want to enable this during testing and let them choose for themselves in their builds.
Note, that this expands the scope of -Werror to our entire repo for CI, so a bunch of fixes and opt-outs had to be applied to get this change passing.
Closed#14714
PiperOrigin-RevId: 666903224
If there's an unexpected failure message or an unexpected succeeding test from a wildcard expansion users will be made to remove the wildcarded equivalent. Once removed, they must rerun the conformance test to add the failures contained within the removed wildcarded equivalent.
PiperOrigin-RevId: 663040062
For some reason, the current if statement also causes the blocking test to be skipped if any of the needs are skipped. We fix this by going back to `if: always()` to ensure that this is always run.
PiperOrigin-RevId: 663033872
Before this PR, we stored a list internally of tests that must pass on presubmit and tried to keep it up to date.
This PR moves that information keeping into GitHub by adding a 'continuous-only' variable to most testing matrices to allow authors to specify which of their tests should be skipped on presubmit. During presubmit, tests that were specified to not run on presubmit will not be run and their names will be prefixed with "[SKIPPED]". All continuous only tests will be suffixed with "(Continuous)".
At the end of running all the tests, we have a single "All Blocking Tests" signal that will tell us whether all of the necessary tests have passed (either for presubmit or continuous based on how the test was triggered).
I've tested this from a different branch [here](https://github.com/protocolbuffers/protobuf/actions/runs/9602443750?pr=17151) and from a different fork [here](https://github.com/protocolbuffers/protobuf/actions/runs/9602554500?pr=17192). These should be the same and are as far as I can tell.
I also have a continuous test run [here](https://github.com/protocolbuffers/protobuf/actions/runs/9603824200) which runs the entire test suite.
Closes#17198
PiperOrigin-RevId: 662940724
We mostly use generated pom files in our release currently, so we can delete all the files that aren't used and the tools to update them.
Note, java/bom/pom.xml java/pom.xml and java/protoc/pom.xml are all still used at release and java/kotlin/pom.xml is used for documentation so all of those need to stay for now.
PiperOrigin-RevId: 659664012
This allows us to test our maven setup without relying on static `pom.xml` files and clears the way to remove them in a subsequent CL.
PiperOrigin-RevId: 658057911
Something has changed between Xcode and xcpretty such that
we don't get full logs when something fails to know what
file/line is actually failing; so stop using it.
PiperOrigin-RevId: 654830446
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
These classes are deprecated and will be removed in the next breaking change. Users should update gencode to >= 4.26.x which uses GeneratedMessage instead of GeneratedMessageV3.
Tested with //compatibility:java_conformance_v3.25.0 which builds the runtime against 3.25.0 gencode.
PiperOrigin-RevId: 644136172
In this first stage, we rename the directory from protos_generator to hpb_generator, updating all necessary BUILD files and #includes.
PiperOrigin-RevId: 642600953
There is a special case where message factories can be confused: if a module
written in C++ with pybind11 links against a self-recursive message, and that
message is part of another message loaded from Python, then the confusion
will happen.
Example:
# This one is also linked into the C++ module.
message SelfRecursive {
optional SelfRecursive self_recursive = 1;
}
# This one is used only in Python and not linked.
message OnlyUsedInPython {
optional SelfRecursive self_recursive = 2;
}
The caching through message_factory::RegisterMessageClass then happens on one
instance of the factory, but traversal with the lookup in another.
This occurs in the pure Python and upb implementations that have their own
default descriptor pools (and thus message factory).
Fix this by using the already passed message factory to registering the
message class to cache.
A test accounts for this case to avoid regressions.
PiperOrigin-RevId: 642551744
This will reduce unnecessary resource consumption by cancelling running workflows when new commits are pushed to a PR or workflow dispatch. It does not cancel pushes to main or branches.
Closes#16601
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16601 from sethvargo:sethvargo/actions-concurrency 82fd070dba
PiperOrigin-RevId: 629805311
This will allow them to reuse our bazelrc and remote caching setup. This also silences the non-bzlmod windows test that's hitting the windows path length.
PiperOrigin-RevId: 626390416
We're seeing a high flake rate due to remote cache-misses only on Bazel 7 builds. The key change here seems to be adding the remote_download_output flag, but this also upgrades us to 7.1.1 and adds some retry behavior to caching issues.
PiperOrigin-RevId: 625892332
I'm not sure why exactly but GitHub Actions is complaining about the reference
to `matrix.PLATFORM`. Let's just delete that and the visionos builds until
we're ready to turn visionos back on.
PiperOrigin-RevId: 617922287
Derek Benson
Protobuf Team Bot
Adam Cozzette
Deanna Garcia
Mike Kruskal
Yamil Morales
Thomas Van Lenten
Sandy Zhang
Hong Shin
Jason Lunn
Bastien Jacot-Guillarmod
Seth Vargo
Alex Eagle