Optimize windows CI build

[lalitb]

Currently taking > 1hr, I think specifically for gRPC build:

[ThomsonTan]

Does this long running build block merging PR now?

[dbarker]

The longest running windows job now appears to be one I added .github/workflows/cmake_install.yml#L14 which builds/tests all components in one step then builds/tests the dll component in a second step.

A recent run of this job took 43 min to build the vcpkg packages followed by ~18 min for each test run step. Most of the vcpkg build time is on the grpc package. It seems vcpkg builds both release and debug.

A few minutes can be saved by not building unused grpc plugins (most are built by default). It may also be possible to only build debug and not release. The bigger savings likely comes from caching the vcpkg built binary packages.

Caching the packages seems reasonable:

• Cache with NuGet: https://learn.microsoft.com/en-us/vcpkg/consume/binary-caching-github-packages?pivots=windows-runner
• Cache with Github Actions Cache: https://learn.microsoft.com/en-us/vcpkg/consume/binary-caching-github-actions-cache

[ThomsonTan]

The longest running windows job now appears to be one I added .github/workflows/cmake_install.yml#L14 which builds/tests all components in one step then builds/tests the dll component in a second step.

A recent run of this job took 43 min to build the vcpkg packages followed by ~18 min for each test run step. Most of the vcpkg build time is on the grpc package. It seems vcpkg builds both release and debug.

A few minutes can be saved by not building unused grpc plugins (most are built by default). It may also be possible to only build debug and not release. The bigger savings likely comes from caching the vcpkg built binary packages.

Caching the packages seems reasonable:

• Cache with NuGet: learn.microsoft.com/en-us/vcpkg/consume/binary-caching-github-packages?pivots=windows-runner
• Cache with Github Actions Cache: learn.microsoft.com/en-us/vcpkg/consume/binary-caching-github-actions-cache

I think binary caching was discussed before, and cache with the container with grpc build was 5 or 6GB, and may be even bigger for now.

For cache with NuGet, we have OpenTelemetry .NET publishing package to NuGet, probably we can use the same setting to cache vcpkg blob for gRPC?

[dbarker]

I think binary caching was discussed before, and cache with the container with grpc build was 5 or 6GB, and may be even bigger for now.

For cache with NuGet, we have OpenTelemetry .NET publishing package to NuGet, probably we can use the same setting to cache vcpkg blob for gRPC?

Thanks for the background. Yeah if the vcpkg packages from our vcpkg submodule tag are already cached somewhere trusted/accessible it may not be a big step to configure this project's ci jobs to use the cache.

[github-actions]

This issue was marked as stale due to lack of activity.