We currently use the search API to check for duplicate pull requests,
but this is not very reliable. Our `autobump.yml` workflow routinely
opens duplicate pull requests [1] because the search API often returns
incorrect results.
We can make this more reliable by using the Pulls API instead.
Unfortunately, querying the Pulls API is very slow (~10s vs less than a
second for the search API), so let's limit its usage to calls made
inside CI, which should help @BrewTestBot avoid opening duplicate PRs.
(Most recent dupes were authored by @BrewTestBot.)
[1] https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+author%3ABrewTestBot+is%3Aunmerged+in%3Acomments+Duplicate
`#curl_headers` was recently introduced into `Strategy#page_headers`
but only the call was modified and the method wasn't updated to
correctly work with the new return value, so all `HeaderMatch` checks
immediately started failing with an error.
This commit includes changes that return `#page_headers` to a working
state. I've removed the `result.assert_success!` call because it
prevents a few checks from being retried with `GET` (`firefox-cn`,
`krisp`, `prepros`).
These were introduced by typos and an incorrect assumption on the last
update of #15358. The last commit had been tested with a parameter, but
had not been re-tested *without* parameter.
Apologies for the error.
We need to exclude any command that might read `lsyncd` on Linux while
simulating macOS. This seems like all of them.
This reverts commit bcf94f6e27d26a6844ee1fa7af73333321015987.
It's standard for the `match_data` to include the URL (e.g., as in
`PageMatch`). This uses the provided URL by default, switching to the
generated URL when available.
- Thanks to Markus on Slack for saying "the cop should only apply to the
content of the blocks, or more specifically only to stanzas that are
direct children of cask or on_* blocks", which made me realize that
I was overcomplicating things.
- Now that we detect correct stanza _grouping_ within `on_*` blocks in
Casks (PR 15211), correct stanza _ordering_ in `on_*` blocks was the
next logical step. For example, `url` has to come after `version` and
`sha256` in an `on_macos` or `on_intel` block for consistency with the
top-level stanza order we enforce elsewhere.
- Still not doing the nested `on_os` inside `on_arch`, that felt
excessive for an edge case that isn't present in any actual real
Casks we have. I removed the test with that specific TODO.
