Chiebot-Mirror/protobuf - protobuf - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Mike Kruskal	5127af50f2	Switch to Ninja generator for windows cmake builds. 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	2 years ago
Mike Kruskal	9c2211be08	Switch to Ninja generator for windows cmake builds. 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	2 years ago
Mike Kruskal	0ed65fd08f	Enable github caching of Bazel's repository cache. 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	2 years ago
Mike Kruskal	05f15196c2	Fix permissions of ccache directory in cmake image PiperOrigin-RevId: 507684370	2 years ago
Mike Kruskal	c399aeccc4	Enable ccache for CMake builds. 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	2 years ago