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
Add the objects to the object graph and balance the retain count before
doing the parsing. This ensure if an error is hit (and a throw happens),
the object(s) won't be leaked.
Parsing will always mutate the graph, so yes this includes more mutations
in failure cases, but other fields could always be modified before the
bad data is encountered. But even then, that edge case *only* apples to api
users that are explicitly *merge* (-mergeFrom...), the majority of the calls
are to +parseFromData:error:, so the entire graph is released on failure.
PiperOrigin-RevId: 510417377
The last attempted (rolled back) resulted in changes in visible behavior:
- It consumed a recursion depth on the input stream (wrong)
- It resulted in different error codes for some malformed/truncated data.
PiperOrigin-RevId: 510415215
Unconditional update of isMutable causes data races for
LazyStringArrayList::EMPTY_LIST that is used as the default value
for protobuf fields.
Not writing to it unconditionally may also improve performance
by reducing contention for the presumably widely shared EMPTY_LIST object.
PiperOrigin-RevId: 510366298
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
This fixes some relatively harmless flakiness in our post-submit. If two commits are made within ~5 minutes of each other, the `git push` command will fail because the git workspace isn't up to date.
PiperOrigin-RevId: 510165977
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
Protobuf Team Bot
Martijn Vels
Protobuf Team Bot
Mike Kruskal
Jakob Buchgraber
deannagarcia
Deanna Garcia
zhangskz
Mike Kruskal