This migrates from reusable workflows to composite GHA actions. This has the following advantages:
1) We can split them into smaller, easier to reason about chunks
2) We can reuse them more freely between each other and workflows
3) They don't complicate the job names
4) In theory they'll be easier to test in isolation. While composite actions can't be unit-tested, we can easily break them up into nodejs or docker actions that can be.
As a proof of concept, some of our non-Bazel tests are migrated to GHA as well (CMake + Composer)
Closes#11718
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11718 from protocolbuffers:gha-actions 5403307bc00616e94816aa460813939d8f37a1bd
PiperOrigin-RevId: 506375417
Our repo settings have already been updated to only allow merges from the BTR team and protobuf managers. Except for some very specific circumstances, PRs should *never* be merged and should instead be imported via Copybara.
PiperOrigin-RevId: 506371362
This is a proof of concept that we can experiment with before migrating all of our Kokoro tests to GHA. In addition to the migration, this builds out infrastructure for safe handling of both external and internal contributions. Two of the existing GHA workflows have also been migrated to this system to unify how we handle testing.
To test the new workflow introduced here, you can open PRs to the `gha` branch. This feature branch acts as a staging area for GHA. PRs opened up from this repo will automatically have all tests run on each commit. We will also run them all as post-submits, and continuously on a daily schedule. PRs opened from forked repos will need per-commit approval for each test run, which can be given by adding the `safe for tests` label.
Examples (failures are intentional to show that the PR code is being tested):
- Internal PR: https://github.com/protocolbuffers/protobuf/pull/11679
- Fork PR (approved): https://github.com/protocolbuffers/protobuf/pull/11685
- Fork PR (rejected): https://github.com/protocolbuffers/protobuf/pull/11683
- External PR: https://github.com/protocolbuffers/protobuf/pull/11695Closes#11702
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11702 from protocolbuffers:gha f3a2663896
PiperOrigin-RevId: 506169444
There already are explicit checks in debug builds, but this adds an addition
check within all builds to catch when unknown flags are being passed to the
runtime, which is an indication that the source generation is from a newer
version of the library.
PiperOrigin-RevId: 506091257
When generating Ruby clients for proto3 messages that have a oneof, we generate a hazzer for members of the oneof, not just a hazzer for the oneof itself.
In other words, for a proto like this:
```
syntax = "proto3";
message Foo {
oneof bar {
string baz = 1;
}
}
```
The generated `Foo` will now have a method called `has_baz?`, in addition to the (pre-existing) method `has_bar?`.
I updated the unit tests, and verified that all the tests under `//ruby/...` pass.
Fixes https://github.com/protocolbuffers/protobuf/issues/9561.
Closes#11655
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11655 from shaldengeki:test-ruby-oneof-hazzer a15e474da6
PiperOrigin-RevId: 506090930
We will aim to get binary gems in 3.22.0, but if they aren't done we will do an all source release and bump to 4.22.0 at full release time.
PiperOrigin-RevId: 506075942
Descriptor was relying on the Root for the runtime check, but since the Root is
only startup up when needed, add the debug runtime check to the cases where the
Root isn't started up.
EnumDescriptors are normally started up by fields, but a developer could
directly call the public apis, so add the debug runtime check for safety sake.
PiperOrigin-RevId: 506062884
Looking back through history, figure out each place a generation change was
added and added compile asserts to help leave signals for what can be cleaned up
when if the legacy support is ever moved forward.
PiperOrigin-RevId: 506020387
Several of the classes vended by the runtime don't really support subclassing,
so mark them as such to get compiler enforcement just in case.
PiperOrigin-RevId: 505221732
Since it really just wraps some basic types, there are lots of instances
that are actually the same content wise, so to better match the contract
for NSObject it should compare the fields.
PiperOrigin-RevId: 505167021