We're having issues with github runners right now where they're queueing for long periods, and this has become disruptive. We've gotten the flake rate under 2% total (<0.5% per build), and can ramp this up again later if we want to reduce it further.
PiperOrigin-RevId: 575227138
This change moves the upb Fastbuild, Optimized, and FastTable test runs over to
the protobuf repo CI in preparation for moving the upb codebase itself. There
are a bunch more test runs to move, but this initial change handles the easy
ones first.
I also updated our pinned upb version to the current head to pick up some
recent fixes.
PiperOrigin-RevId: 557486174
These are designed to only run once daily in "quiet" hours to avoid race conditions. While isn't very harmful, it does cause our monitoring to show an artificial increase in flakes.
PiperOrigin-RevId: 544883830
- Do some minimal sanity testing on every PR
- Only run the staleness tests on a daily schedule or explicit runs.
- Add 23.x to the checks
PiperOrigin-RevId: 537952151
Both 'schedule' and 'workflow_dispatch' are valid alternatives today. What we really want here is anything *except* pull request events.
PiperOrigin-RevId: 509123777
Both 'schedule' and 'workflow_dispatch' are valid alternatives today. What we really want here is anything *except* pull request events.
PiperOrigin-RevId: 509123777
Changes to these files *can't* be tested in forked PRs, so we should explicitly block them with an error message to explain why.
PiperOrigin-RevId: 508701535
- General naming up to "Objective-C" that some linters want, so just
use it every where for consistence.
- Add a bazel macOS config
- Includes the conformance test, so drop it from the Xcode flows.
- Tweak the naming on the Xcode flows so they are a little more clear.
- CocoaPods flows:
- Give them (hopefully) clear naming
- Use the same `image` as the Xcode tests
- Pin the Xcode version to match the Xcode tests
PiperOrigin-RevId: 508156130
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
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
Mike Kruskal
Sandy Zhang
Adam Cozzette
Joyce
Jakob Buchgraber
Protobuf Team Bot