Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.46%. Comparing base (a407be2) to head (99d44ce).

@@           Coverage Diff           @@
##             main    #1978   +/-   ##
=======================================
  Coverage   89.46%   89.46%           
=======================================
  Files          16       16           
  Lines        5838     5838           
=======================================
  Hits         5223     5223           
  Misses        615      615           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for this! Is this redundant with .github/actions/cache, which is also called from generate_cache? That was added in #835. I'll be honest that I'm not sure whether we need both the generate_cache job and the .github/actions/cache action - I'm a little rusty on the semantics of GitHub Actions in this case.

Thanks for this! Is this redundant with .github/actions/cache, which is also called from generate_cache? That was added in #835. I'll be honest that I'm not sure whether we need both the generate_cache job and the .github/actions/cache action - I'm a little rusty on the semantics of GitHub Actions in this case.

No, you are RIGHT!!! I should use that composite.
There are two modifications here

1. Fetch the output from the steps. Accessing the output directly is not straightforward, but I understand the purpose of this extra layer of delegation—it ensures that the output remains consistent in the composite, regardless of the action packages used or the varying output names.
2. I added restore-key to the composite step. This allows for a broader cache key range. See if this one is helpful?!

Okay, that makes sense! And indeed, this seems to have considerably sped up CI:

Compare to this run for #1981: