The `Bitbucket` strategy currently matches versions from tag
tarball links on a project's `downloads/?tab=tags` page. It appears
that Bitbucket now uses a hash as the filename on this page instead
of the tag name, so the existing regex no longer matches.
This adds an alternative regex to match versions from the tag name
element (e.g., `<td class="name">example-1.2.3</td>`), which will fix
version matching in this scenario.
The `#versions_from_content` method requires a regex and this will be
enforced by the type signature, so we don't have to check for the
presence of a regex when handling a `strategy` block.
The initial documentation comments contained some remaining text
referring to `GithubLatest` and hadn't been updated to incorporate
the recent changes to the aforementioned strategy. This also reworks
some of the language to better explain the strategy's function,
application, etc.
The default curl args in `#curl_headers` cover most of
`Livecheck::Strategy::DEFAULT_CURL_ARGS` but `--max-redirs` was
overlooked. This adds an explicit `--max-redirs` argument in
the `#page_headers` `#curl_headers` call but it's worth mentioning
that this approach wouldn't benefit from any changes in
`DEFAULT_CURL_ARGS` and would need to be manually kept in parity.
`#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`).
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.
Since we use `REXML::Document` in the type signature for `#parse_xml`,
we can encounter an `uninitialized constant
Homebrew::Livecheck::Strategy::Xml::REXML` error in strategies like
`Sparkle` that use `Xml#parse_xml` internally when the Sorbet runtime
is used. Moving the related require outside of the `#parse_xml` method
and into the `Xml` strategy proper resolves this issue.
`content` can be `nil` when a request doesn't succeed but
`#versions_from_content` expects a `String` value, so we need to
guard against a `nil` value like we do in other strategies.
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.
This updates `ElectronBuilder` to use `Yaml#find_versions`, as the
only code unique to that strategy is to restrict regex usage and
use default version-finding logic when a `strategy` block isn't
provided. This is similar to how we have various strategies that
use `PageMatch#find_versions` internally.
This allows us to remove `ElectronBuilder#versions_from_content`
entirely, along with the related tests. I've added support for
`provided_content` to `ElectronBuilder#find_versions` as a way of
adding tests and maintaining code coverage.
This adds a generic `Yaml` strategy to livecheck that requires a
`strategy` block to operate. The YAML-parsing code is taken from the
existing approach in the `ElectronBuilder` strategy.
We don't currently have any `strategy` blocks in first-party taps
that manually parse YAML. However, creating a generic `Yaml` strategy
allows us to simplify `ElectronBuilder` (and any future strategy
that works with YAML) while making it easy to create custom `Yaml`
`strategy` blocks in formulae/casks as needed.
This setup mimics the `#parse_xml` method that was implemented in the
`Xml` strategy. Isolating the parsing code means that other strategies
can take only what they need from `Json` (i.e., it's not required for
them to use `Json#find_versions`).
This adds a generic `Xml` strategy to livecheck that requires a
`strategy` block to operate. The XML-parsing code is taken from the
existing approach in the `Sparkle` strategy. As such, `Sparkle` has
been updated to use the `Xml#parse_xml` method instead.
Unlike the `Json` strategy, we don't currently have any `strategy`
blocks in first-party taps that manually parse XML. However, we had a
user request support for something like this and I was already working
on an `Xml` strategy (as a way of extracting the XML-parsing code
from `Sparkle` into something general-purpose), so here we are.
Future strategies that parse simple XML data can potentially use the
`Xml#find_versions` method (similar to how we have strategies that
leverage `PageMatch#find_versions`) instead of having to implement
something bespoke like `Sparkle`.
