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.
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.
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`.
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`).
The `ElectronBuilder` strategy uses `YAML#safe_load` to parse YAML
content and this limits deserialization to appropriate classes. We
recently encountered a `Tried to load unspecified class: Time` error
when using the `ElectronBuilder` strategy on a `latest-mac.yml` file
containing `releaseDate: 2022-12-01T02:02:46.419Z`.
The electron-builder YAML files we usually encounter use single
quotes around the `releaseDate` value to ensure it's treated as a
string (e.g., `releaseDate: '2022-10-12T17:55:26.718Z'`) and this is
what we do in `electron_builder_spec.rb`. The aforementioned YAML
file doesn't use single quotes around the value, so it's treated as
a timestamp and apparently this makes Psych use `Time` (which
`#safe_load` doesn't allow by default).
Seeing as we can't control the YAML content and there's a chance we
may encounter other files like this in the future, this commit
modifies the related `#safe_load` call to allow `Time` (and `Date`
for good measure). This will resolve the aforementioned error and
allow the `ElectronBuilder` strategy to work as expected in this
scenario.
- This was done with `brew typecheck --update --suggest-typed` which
(as of the previous commit) uses Spoom, yet another gem. I thought I'd
see how well it works. There are no Sorbet errors after these changes!
The `Gnome` strategy's default regex uses the `+` form of the standard
regex for matching versions like 1.2.3. However, with the switch to
the new version scheme, some packages had a release that omits a
minor and patch (i.e., `40` instead of `40.0`). The default regex
fails to match versions like this but the looser `*` form will match
both. [When creating regexes, we generally start with the `+` form
and only switch to the looser `*` form when it's necessary and
contextually-appropriate.]
This also updates the default version filtering logic that's applied
to versions using the old GNOME version scheme (below version 40).
Outside of the refactoring changes, this also filters out versions
where the patch number is 90+, as these are also unstable.
The `tags_only_debian` code in livecheck's `Git` strategy was
originally introduced in Homebrew/homebrew-livecheck#131 when
livecheck was in a less mature state and relied more on internal
special-casing like this (i.e., while we worked to add appropriate
`livecheck` blocks). This logic only has the potential to be
beneficial when a formula/cask doesn't contain a `livecheck` block
but I would argue that we shouldn't be making assumptions in the
strategy around whether tags with a `debian/` prefix should be
matched or omitted. The answer depends upon the context of a given
formula/cask and should be handled with a `livecheck` block, as we
do with other situations like this.
In a past discussion, it was preferred that we use `system_command`
in livecheck's `Git` strategy instead of `Open3.capture3` but it
wasn't feasible at the time because we couldn't prevent
`#system_command` from printing certain output. I resolved the
`SystemCommand` shortcoming long ago in Homebrew/brew#10066, so this
finally migrates the `Git` strategy to `system_command`.
Making `channel` information available in the `Item` is necessary
to be able to filter out unstable items using a `strategy` block. If
an item doesn't specify a channel, then it uses the default channel
(this is what Sparkle itself uses for updates). Channels like `beta`
are something we want to avoid for stable casks and this allows for
that type of [cask-specific] filtering.
It's technically possible to automatically filter out items that
aren't using the default channel (i.e., `channel != nil`) in
`#items_from_content` but some casks use an unstable version, so we
can't do this internally. That is to say, we wouldn't be able to
override internal filtering in a `strategy` block, as any omitted
items wouldn't be provided to the block. Conversely, if we pass all
items to a `strategy` block, we can easily filter by channel there.
We haven't been filtering by channel internally and we've only found
one cask where this has been a problem, so it seems fine for now.
It's sometimes necessary to work with all the items in a Sparkle feed
to be able to correctly identify the newest version but livecheck's
`Sparkle` strategy only passes the `item` it views as newest into a
`strategy` block.
This updates the `Sparkle` strategy to optionally pass all items into
a `strategy` block, so we can manipulate them (e.g., filtering,
sorting). This is enabled by naming the first argument of the
strategy block `items` instead of `item`. `Sparkle` `strategy` blocks
where the first argument is `item` will continue to work as expected.
This necessarily updates `#item_from_content` (now
`items_from_content`) to return all items. I've decided to move the
sorting out of `#items_from_content`, so it simply returns the items
in the order they appear. If there is ever an exceptional situation
where we need the original order, this will technically allow for it.
The sorting has instead been moved into the `#versions_from_content`
method, to maintain the existing behavior. I thought about passing
the items into the `strategy` block in their original order but it
feels like sorting by default is the better approach for now (partly
from the perspective of maintaining existing behavior) and we can
always revisit this in the future if a cask ever requires the
original order.
Lastly, this expands the `Sparkle` tests to increase coverage. The
only untested parts are `#find_versions` (which currently
requires a network request) and a couple safeguard `raise` calls
when there's a `REXML::UndefinedNamespaceException` (which shouldn't
be encountered unless something is broken).
