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
Both 'schedule' and 'workflow_dispatch' are valid alternatives today. What we really want here is anything *except* pull request events.
PiperOrigin-RevId: 509123777
These will still use MSVC as the compiler, but will no longer generate Visual Studio projects for the builds. Visual Studio is particularly bad at parallelizing builds, and is hostile to ccache.
This change also tweaks the ccache setup to prevent unbounded the growth observed in our github caches. Windows builds have had debug symbols stripped to reduce ccache size by a factor of 2x, and ccache maximum have been tweaked so that we persist fewer older builds.
Before this change, each CMake build took 12 minutes on every run (plus some constant overhead from staleness/gcloud), even with caching or on large multi-core runners. No amount of caching or parallelization made any noticeable difference above noise. With this change, we see the following improvements:
- 12 minutes to build from scratch on normal runners (unchanged)
- 4 minutes on 32-core runners from scratch
- 1 minute with optimal caches available on normal runners.
- 30 seconds on 32-core runners with optimal caches
PiperOrigin-RevId: 508799909
Use the bash GHA to ensure WKTs are current, and then just directly invoke
Xcode. This means the script full_mac_build.sh can go back to just being
a simpler helper for folks doing local builds and we can remove all the extra
support that was needed for CI.
PiperOrigin-RevId: 508762464
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
Both 'schedule' and 'workflow_dispatch' are valid alternatives today. What we really want here is anything *except* pull request events.
PiperOrigin-RevId: 509123777
These will still use MSVC as the compiler, but will no longer generate Visual Studio projects for the builds. Visual Studio is particularly bad at parallelizing builds, and is hostile to ccache.
This change also tweaks the ccache setup to prevent unbounded the growth observed in our github caches. Windows builds have had debug symbols stripped to reduce ccache size by a factor of 2x, and ccache maximum have been tweaked so that we persist fewer older builds.
Before this change, each CMake build took 12 minutes on every run (plus some constant overhead from staleness/gcloud), even with caching or on large multi-core runners. No amount of caching or parallelization made any noticeable difference above noise. With this change, we see the following improvements:
- 12 minutes to build from scratch on normal runners (unchanged)
- 4 minutes on 32-core runners from scratch
- 1 minute with optimal caches available on normal runners.
- 30 seconds on 32-core runners with optimal caches
PiperOrigin-RevId: 508799909
Use the bash GHA to ensure WKTs are current, and then just directly invoke
Xcode. This means the script full_mac_build.sh can go back to just being
a simpler helper for folks doing local builds and we can remove all the extra
support that was needed for CI.
PiperOrigin-RevId: 508762464
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 should substantially reduce network flakes, since most builds will no longer need to download external dependencies. Because these caches actually get pretty expensive (~300 MB just from 1 openjdk dependency), we've taken some precautions:
1) The caches only get updated on push events (i.e. post-submit jobs)
2) Only a single job will push a new cache for any os/branch/commit combination. This will be whichever job finishes its bazel run first, and *also* has updates for the cache. Over time, the cache should expand to the full set of transitive dependencies as the quicker jobs stop pushing updates.
3) A clear_caches workflow has been introduced to reset the caches in case they grow too large. This will run monthly for now, but can also be run manually.
PiperOrigin-RevId: 508133044
This has the consequence of removing the path filter, but allows us to actually use these test results as presubmits. Since these are relatively cheap tests, this seems like a better situation. A future enhancement may restore path filters to these and other tests.
PiperOrigin-RevId: 507872208
The `BuildInParallel` flag only controls parallelism at the *project* level, while `/MP` enables it at the *compilation unit* level.
PiperOrigin-RevId: 507837073
This uses ccache + github caching to substantially decrease the time it takes to run XCode builds. Due to Bazel caching, these are some of our slowest tests, causing one of the biggest presubmit bottlenecks
PiperOrigin-RevId: 507794241
This uses ccache + github caching to substantially decrease the time it takes to run CMake builds. Due to Bazel caching, these are some of our slowest tests, causing one of the biggest presubmit bottlenecks
PiperOrigin-RevId: 507667813
Mike Kruskal
Deanna Garcia
Protobuf Team Bot
Sandy Zhang