attestations: batch attestation requests to reduce GH API load #18544
Description
Verification
- This issue's title and/or description do not reference a single formula e.g.
brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.
Provide a detailed description of the proposed feature
This is a tracking issue for myself.
GitHub ratelimits their attestation APIs. These ratelimits are mostly fine when authenticated, but are severe when unauthenticated. However, even when authenticated, we're currently regularly getting close to them on CI (since the CI performs a lot of attestation verifications while performing bottle builds + test installs).
We can significantly reduce the amount of individual GH API calls we make by batching our attestation lookups. Instead of performing one gh attestation ...
subcommand per attestation, we can instead pre-compute the list of attestations to look up and fetch them in a bulk fashion by requesting them in a single gh attestation ...
invocation. gh attestation ...
should then download them in an appropriate batched fashion internally.
What is the motivation for the feature?
Three main motivations:
- Reliability/reducing our baseline GH API load: fewer separate downloads means fewer network requests that can fail for reasons outside of our control. It also means fewer hits counted against both our (CI) and user-level API tokens, making it less likely that users will see ratelimiting errors.
- Performance: doing attestation downloads and verification in bulk upfront can be made embarrassingly parallel, either at the
gh
level or at thebrew
level. It also reduces the number ofgh
subprocessesbrew
needs to spawn, which are also slow. - Post
gh
transition: downloading the attestations up-front means we can more easily slotsigstore-ruby
in for verification.
How will the feature be relevant to at least 90% of Homebrew users?
Reliability and performance, per above.
What alternatives to the feature have been considered?
Two options:
- Leave things as they are.
- Perform a more aggressive refactor that avoids the attestation APIs entirely, by instead stapling attestations to container manifests/metadata (is this the right term?) and retrieving them in-line with bottle downloads from GHCR. This would bypass the ratelimit concerns with attestations, but might have some undesirable knock-on effects (such as making 3p tap attestation support harder, since not all 3p taps use containers for bottle distribution).