attestion: make InvalidAttestationError non-fatal in CI

[carlocab]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

I don't think I've seen an InvalidAttestationError that wasn't some
sort of network problem (e.g., rate limit, connection timeout, 503).
Let's emit a warning instead of erroring out.

Note that MissingAttestationError is still fatal, and that will still
produce errors in CI.

[carlocab]

attestation.rb:135: Method `system_command!` does not exist on `T.class_of(Homebrew::Attestation)` https://srb.help/7003
     135 |        result = system_command!(gh_executable, args: cmd,
                           ^^^^^^^^^^^^^^^
Errors: 1

Huh, interesting. Not even code I touched though. Would love a suggestion here. CC @dduugg ?

[MikeMcQuaid]

I appreciate the intent here but 👎🏻 as-is.

If we're going to make this non-fatal it feels like it defeats the entire point of having attestation.

I'd like to have us try a couple of retries with an exponential backoff before we do this.

[dduugg]

attestation.rb:135: Method `system_command!` does not exist on `T.class_of(Homebrew::Attestation)` https://srb.help/7003
     135 |        result = system_command!(gh_executable, args: cmd,
                           ^^^^^^^^^^^^^^^
Errors: 1

Huh, interesting. Not even code I touched though. Would love a suggestion here. CC @dduugg ?

Try pairing your change with an explicit begin, since i don't think the way code aligns matches the control flow. (Then, I think you should be getting a different type error, since you've made the return type nilable)

[carlocab]

Implemented retry logic instead.

[MikeMcQuaid]

Thanks @carlocab! Have suggested speeding up failure time so we can evaluate if this is something we should back out entirely for now. Feel free to merge as-is if preferred.

[carlocab]

Let's keep the retry timing as is. The case for backing this out if we need to will be stronger if we were more patient about retries.