audit: respect livecheck throttle days

[bevanjkay]

---

• 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? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you written new tests (excluding integration tests) for your changes? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) with your changes locally?

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes. Non-maintainers may only have one AI-assisted/generated PR open at a time.

I used Codex to help find the discrepancy between the brew livecheck and brew audit behaviour.

---

With the recent introduction of the days parameter to livecheck throttle, the behaviour has been updated to be correctly reflected across brew bump and brew livecheck - however brew audit was not receiving the change, as discovered in Homebrew/homebrew-cask#260573

[Copilot]

Pull request overview

Updates brew audit’s cask livecheck version validation to honor the newer livecheck throttle days: setting (including when throttling is inherited via a referenced cask), aligning behavior with brew livecheck and bump commands.

Changes:

• Extend cask audit livecheck logic to consider throttle_days (and referenced-cask throttle_days) when selecting latest vs latest_throttled.
• Add cask audit specs covering throttle days: on a cask and via a referenced cask.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
Library/Homebrew/cask/audit.rb	Makes audit’s livecheck version comparison respect throttle days: (including from referenced casks).
Library/Homebrew/test/cask/audit_spec.rb	Adds new spec contexts for throttle days: and referenced-throttle-days scenarios.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MikeMcQuaid]

Looks good when you're happy and have all the reviews you want!

[samford]

This makes sense to me but this change doesn't appear to fully resolve the audit issue when tested on the linked alma homebrew-cask PR branch, as livecheck is giving a latest_throttled version of 0.0.750 (the latest version meeting the throttle rate) instead of 0.0.762 (the latest version, as the throttle days interval elapsed).

This happens because time-based throttling uses Git commit timestamps to identify when the package was last updated but formula_or_cask_last_updated_timestamp returns the timestamp for the 0.0.762 version update commit in the PR branch, so the throttle interval isn't viewed as having elapsed when auditing the cask. This approach works fine on the main branch (e.g., when running brew bump to update packages) but not when on a version update branch.

One solution would be to modify the git log command in formula_or_cask_last_commit_timestamp to only identify commits on the repository's default branch (i.e., main for homebrew-cask). I've confirmed that this works as expected in practice, so I'll push a commit with this change if that makes sense to you.

[bevanjkay]

Thanks @samford - please go ahead and push the changes.

[samford]

With the change to the git log command, the audit correctly gives the latest version as latest_throttled when auditing the alma PR. I'm going to go ahead and approve this but let me know if there's room for improvement in the Git changes.

We could technically hardcode main as the default branch if we were only working with first-party taps but I figured it would be better not to assume, as this programmatic approach should also work for third-party taps. In this setup, I'm simply using "main" as a reasonable fallback (though I tested this without the fallback to make sure it worked as expected first).

---

Regarding latest_throttle potentially being nil, the audit will fail when that happens and I think that's fine. Autobump shouldn't be creating a PR in that scenario, so this should only happen if someone updates a version bump PR for a throttled version and we want CI to fail in that case. We can always revisit this and expand the audit logic if it becomes an issue in practice.

[MikeMcQuaid]

Thanks @bevanjkay and @samford!