This is inspired by https://github.com/protocolbuffers/protobuf/issues/12306,
but does not show those failures, so clearly it doesn't catch everything, but
figured some coverage is better than none.
PiperOrigin-RevId: 525134469
Github doesn't currently have Apple Silicon runners, but we can build for
the target to atleast ensure things are building.
PiperOrigin-RevId: 524929865
Github doesn't currently have Apple Silicon runners, but we can build for
the target to atleast ensure things are building.
PiperOrigin-RevId: 524929865
The intent of this change is to take the best ideas from the C++ backend, such as having generator objects that can cache pre-computed state, while minimizing duplication.
Where possible, we take the approach of making the C++ and UPB kernel-specific code as similar as possible, since this reduces the number of templates we need to keep in sync.
PiperOrigin-RevId: 524903073
An earlier change inadvertently disabled several GitHub Actions due to a syntax error.
This broke the CI for upb because several expected tests were never running.
I was not able to get the Windows CI test fully working, so I disabled it for now.
PiperOrigin-RevId: 522652505
This turns out to be quite of a yak shave to be able to perfectly test both kernels without having to pass extra Blaze flags.
PiperOrigin-RevId: 521850709
We recently saw a failure pass through where requirements.txt was updated in a way that was not compatible with some python versions. This updates the tests to directly use requirements.txt to download requirements to catch issues like this in the future.
Closes#1237
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/upb/pull/1237 from protocolbuffers:useRequirementsGHA 22a963468e068535cbcf772ba41aee0b3a6e2eec
PiperOrigin-RevId: 518962372
PHP 8.2 is around the corner, and they've just published 8.2.0RC2.
So, what about testing protobuf with it?
Also: even if everything compiles and the PHP extension can be used, we may have that PHP throws some warnings at startup.
For example, if we install protobuf 3.18.3 with PHP 8.1, we have these warnings:
```
$ php -r 'echo "This is just a test.\n";'
Deprecated: Return type of Google\Protobuf\Internal\RepeatedField::offsetExists($index) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in Unknown on line 0
[...omissis... ]
Deprecated: Return type of Google\Protobuf\Internal\MapFieldIter::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in Unknown on line 0
This is just a test.
```
So: what about letting the `php-ext.yml` GitHub Action fail in case we have such startup errors?
Closes#10596
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10596 from mlocati:php-8.2-warnings 6383242b14
PiperOrigin-RevId: 518050302
For legal reasons we unfortunately cannot accept any external contributions to
the well-known type protos, so this change reverts the small number of changes
we have received so far.
PiperOrigin-RevId: 517211904
The internal design is consistent with other <lang>_proto_library rules. rust_proto_library attaches rust_proto_library_aspect on its `deps` attribute. The aspect traverses the dependency, and when it visits proto_library (detected by ProtoInfo provider) it registers 2 actions:
1) to run protoc with Rust backend to emit gencode
2) to compile the gencode using Rustc
Action (2) gets the Rust proto runtime as an input as well.
Coming in a followup is support and test coverage for proto_library.deps.
PiperOrigin-RevId: 514521285
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
This will make PRs from forked repositories significantly less painful, since they'll agree on which version of each action to use. OTOH, we'll have a separate repo that needs to be maintained, and changes to it will need to be coordinated and versioned carefully. This will likely need to be done less often though now that our infrastructure is stable.
PiperOrigin-RevId: 512117705
Fix exit code on git commit which was preventing force-push and tagging from running even though these should work without a new commit. An empty commit is probably clearer anyways to show that sync has happened.
PiperOrigin-RevId: 511255365
Fix exit code on git commit which was preventing force-push and tagging from running even though these should work without a new commit. An empty commit is probably clearer anyways to show that sync has happened.
If a change is committed while we're regenerating stale files, we should just bail and let the next job handle the refresh.
PiperOrigin-RevId: 510453613
Chocolatey doesn't support any caching, so we're moving back to downloading the exe directly. This issue is responsible for a 5-10% flake rate in our windows cmake builds
PiperOrigin-RevId: 510202223
Chocolatey doesn't support any caching, so we're moving back to downloading the exe directly. This issue is responsible for a 5-10% flake rate in our windows cmake builds
PiperOrigin-RevId: 510202223
Bazel has a 2 minute timeout for their internal `xcrun` call, which can be exceeded on our github runners about 5% of the time. This leads to flakes and opaque errors, but is a one-time cost. Subsequent xcruns finish in seconds, so we can just do an initial call w/o a timeout before running Bazel.
With this change our total flake rate drops from ~30% to nearly 0% for our full suite of tests
See https://github.com/bazelbuild/bazel/issues/17437 for background.
PiperOrigin-RevId: 509944178
Bazel has a 2 minute timeout for their internal `xcrun` call, which can be exceeded on our github runners about 5% of the time. This leads to flakes and opaque errors, but is a one-time cost. Subsequent xcruns finish in seconds, so we can just do an initial call w/o a timeout before running Bazel.
With this change our total flake rate drops from ~30% to nearly 0% for our full suite of tests
See https://github.com/bazelbuild/bazel/issues/17437 for background.
PiperOrigin-RevId: 509944178
Adam Cozzette
Joshua Haberman
Thomas Van Lenten
Miguel Young de la Sota
Deanna Garcia
Romfos
Marcel Hlopko
Mike Kruskal
Jakob Buchgraber
deannagarcia
Michele Locati
John Cater
Sandy Zhang
Protobuf Team Bot