`Livecheck#preprocess_url` only contains logic for rewriting Git URLs,
so it makes more sense for this code to be part of the `Git` strategy
instead. Outside of better code organization, this saves us from
having to maintain the list of strategies to skip processing (which
is sometimes forgotten when a new strategy is added) and makes it
easier to do something similar in other strategies as needed.
One thing to note is that `Livecheck#preprocess_url` was previously
called on the URL before each strategy's `#match?` method was called.
To maintain the existing behavior, this calls `Git#preprocess_url` in
`Git#match?`. However, we need the processed URL when we use the `Git`
strategy, so we have to call `Git#preprocess_url` again. To avoid
duplicating effort, I've added a `@processed_urls` hash to the `Git`
strategy and have set up `Git#preprocess_url` to cache processed
URLs, so we only do the work once. There may be a better way of
handling it but this seems to work as expected.
The `url_provided` parameter of the `Strategy#from_url` method was
originally introduced in #9529 but I removed it in a later commit in
that PR in favor of a different approach. Unfortunately, I forgot to
remove the `url_provided` parameter, as it was no longer needed after
that change. This removes the parameter and updates `#from_url` calls
accordingly.
`URI#parse` was originally added in #9074 and replaced with
`Addressable::URI#parse` in #13306 but `require "uri"` wasn't removed
at the time. livecheck doesn't use `URI` now, so this removes the
unused `require`.
`brew livecheck` currently gives a Sorbet type error when run on a
HEAD-only formula: `Parameter 'version': Expected type Version, got
type String with value "c06c10d"`. This happens because the `current`
and `latest` values are strings but `LivecheckVersion#create` expects
a `Version` object.
This addresses the issue by creating a `Version` object from the
related commit strings. This ensures that the type of these variables
is more uniform, which makes them easier to reason about.
This is primarily intended to resolve the `uninitialized constant
Utils::Backtrace` error in `formula_versions.rb:60` but I expanded it
to try to cover all existing usage of `Utils::Backtrace`.
I've followed the existing pattern, where `utils/backtrace` is
required in the context of where it's used. Many of these cases use
`Backtrace` in a conditional manner, so I've tried to ensure that the
`require` follows suit.
From the description of the `--extract-plist` option, it would seem
that the `ExtractPlist` strategy is only enabled when the option is
used. Instead, livecheck automatically enables the strategy if the
command is run on only one cask. This rewords descriptions of the
option to clarify the behavior.
When the `--extract-plist` option was added to livecheck, conditions
were added in `#run_checks` to skip casks using `ExtractPlist` if the
`--extract-plist` isn't used and the run involves multiple
formulae/casks. This integrates the skip into the `SkipConditions`
class.
This was not returning the full name correctly for e.g. anything in
Homebrew/homebrew-fonts.
While we're here, fix up a few other places where `tap.core_cask_tap?`
can be used more appropriately.
Ever since we started using this at runtime it's been polluting
the backtrace output. This makes it harder to debug errors and
increases the amount of info users have to paste into the box
when filing an issue.
This is a very direct approach. Essentially, we strip out
everything related to the `sorbet-runtime` gem whenever the top
line in the backtrace is unrelated to sorbet-runtime.
The hope is that this will allow errors related to sorbet to
be diagnosed easily while also reducing the backtrace size
for all other types of errors.
Sometimes it is useful to see the full backtrace though.
For those cases, we include the full backtrace when
`--verbose` is passed in and print a warning that the
Sorbet lines have been removed from the backtrace the
first time they are removed.
Note: This requires gems to be set up so that the call to
`Gem.paths.home` works correctly. For that reason, it must
be included after `utils/gems` which is included in
`standalone/load_path` already.
We now have a `gitea` formula in homebrew/core and its `stable` URL
uses a dl.gitea.com tarball. Since the URL's domain is gitea.com,
livecheck tries to preprocess the URL into a `.git` URL but the
resulting URL doesn't work because it's not a Git repository.
Gitea repositories use gitea.com (with no subdomain), so
`#preprocess_url` should be comparing the URI host (`dl.gitea.com`)
instead of the domain (`gitea.com`). This change allows gitea.com
repository URLs to continue to be preprocessed into a `.git` URL
while dl.gitea.com URLs are left untouched.
This makes the same change for the other domains, as they don't use
a subdomain either.
The existing way of passing values to `#find_versions` methods in
strategies leads to type issues when the Sorbet runtime is enabled.
We've also recently talked about moving away from nilable args when
we can specify a default value but this doesn't work if we pass in a
`nil` value (like we're currently doing).
This commit aims to address both of those areas by better controlling
which arguments we're passing to `#find_versions`. This approach
naively handles `cask`/`url` arguments by special-casing
`ExtractPlist`.
However, we should be checking the strategy's `#find_versions`
method for a `cask` or `url` keyword parameter. The issue is that
`strategy.method(:find_versions).parameters` is returning
`[[:rest, :args], [:block, :blk]]` instead of the actual parameters
like `[[:keyreq, :url], [:key, :regex], [:keyrest, :unused],
[:block, :block]]`.
I forgot to add the new `Json`, `Xml`, and `Yaml` strategies to the
list of strategies where `#preprocess_url` should be skipped and this
was causing issues for a user in their tap. This is unfortunately
another bug that wasn't surfaced when I tested all the related checks
in our first-party taps.
- 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.
A boolean `resource` parameter was added to `#print_latest_version`
but its only purpose is to identify whether `info` corresponds to a
resource. This can be achieved using `info[:resource].present?`, so
this additional parameter isn't necessary and can be removed.
Minimizing the differences between the `#resource_version` and
`#latest_version` methods will help to ease the process of potentially
merging them into one method in the future.
