- This `Homebrew/utils.rb` file contains one `@api public` method so it's now
included in `Style/Documentation`.
- This method not having a comment was causing the style specs to fail because
this file isn't usually failing RuboCop.
- And the test description was confusing so I improved it.
For casks with certain stanzas, *flight and language
stanzas in this case, we need to use the caskfile
to install them correctly. The JSON API is not an option.
This delays loading from the source API until just before
we try to install one of these casks. This reduces the
number of requests we make to the source API.
Test failure:
```
Failure/Error:
expect(described_class.search_taps("some-formula"))
.to match(formulae: ["homebrew/foo/some-formula"], casks: ["homebrew/bar/some-cask"])
GitHub::API asked to yield |[{"items"=>[{"path"=>"Formula/some-formula.rb", "repository"=>{"full_name"=>"Homebrew/homebrew-foo"}}, {"path"=>"Casks/some-cask.rb", "repository"=>{"full_name"=>"Homebrew/homebrew-bar"}}]}]| but no block was passed
```
Previously, we required all formulae and casks to be in a specific
formula or cask directory but did not check any subdirectories.
This commit allows using subdirectories for official taps, the only
ones likely to be big enough to warrant sharding in this way and to
avoid potentially breaking backwards compatibility for existing taps.
This was inspired by the most recent issues with homebrew-cask.
This adds a generic `Json` strategy to livecheck that requires a
`strategy` block to operate. This is primarily intended as a
replacement for existing `strategy` blocks in formulae/casks that
use `JSON#parse`, as it allows us to internalize/standardize that
boilerplate while improving error-handling.
Additionally, future strategies that parse JSON data can use the
`Json#find_versions` method instead of having to reinvent the wheel
(similar to how we currently have a number of strategies that
leverage `PageMatch#find_versions`).
- These are arbitrary length limits that had a load of disables in code.
- The limits were only increasing over time rather than decreasing.
- Fixing the problematic code to be shorter would take a long time for
questionable gain since the problem has been around so long.
- We're not going to make the really long things be any shorter any time soon.
- The instructions in issue 14685 say, pragmatically, "disable all the rubocop
rules we're never going to realistically fix e.g. Metrics/ClassLength". But
that felt like a slippery slope to more _really_ long modules/classes/blocks,
and the limits are here for a reason.
- Extract update tests into separate tests.
- Make `brew tests --online` run only once in its own job. This job
could be made non-required to fight flakiness.
- Split up the various macOS runs into several steps now that we have
more parallel macOS workers available.
- Cleanup some flaky tests.
