253 lines
8.2 KiB
Ruby
Raw Normal View History

# typed: strict
2020-12-12 21:59:04 +01:00
# frozen_string_literal: true
require "bundle_version"
2020-12-12 21:59:04 +01:00
module Homebrew
module Livecheck
module Strategy
2022-06-09 15:38:02 -04:00
# The {Sparkle} strategy fetches content at a URL and parses it as a
# Sparkle appcast in XML format.
2020-12-12 21:59:04 +01:00
#
2021-08-10 18:38:21 -04:00
# This strategy is not applied automatically and it's necessary to use
# `strategy :sparkle` in a `livecheck` block to apply it.
class Sparkle
2021-08-10 18:38:21 -04:00
# A priority of zero causes livecheck to skip the strategy. We do this
# for {Sparkle} so we can selectively apply it when appropriate.
PRIORITY = 0
# The `Regexp` used to determine if the strategy applies to the URL.
URL_MATCH_REGEX = %r{^https?://}i
# Common `os` values used in appcasts to refer to macOS.
APPCAST_MACOS_STRINGS = T.let(["macos", "osx"].freeze, T::Array[String])
# Whether the strategy can be applied to the provided URL.
2021-08-10 18:38:21 -04:00
#
# @param url [String] the URL to match against
# @return [Boolean]
sig { params(url: String).returns(T::Boolean) }
def self.match?(url)
URL_MATCH_REGEX.match?(url)
end
2021-04-04 03:00:34 +02:00
Item = Struct.new(
# @api public
:title,
# @api public
:link,
# @api public
:channel,
# @api public
:release_notes_link,
# @api public
:pub_date,
2021-04-04 03:00:34 +02:00
# @api public
:os,
# @api public
2021-04-04 03:00:34 +02:00
:url,
# @api private
:bundle_version,
# @api public
:minimum_system_version,
2021-04-04 03:00:34 +02:00
keyword_init: true,
) do
2020-12-19 01:07:56 -05:00
extend Forwardable
2020-12-15 20:26:19 +01:00
# @!attribute [r] version
2021-04-04 03:00:34 +02:00
# @api public
2020-12-19 01:07:56 -05:00
delegate version: :bundle_version
2021-04-04 03:00:34 +02:00
# @!attribute [r] short_version
2021-04-04 03:00:34 +02:00
# @api public
2020-12-19 01:07:56 -05:00
delegate short_version: :bundle_version
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
# @!attribute [r] nice_version
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
# @api public
delegate nice_version: :bundle_version
2020-12-15 20:26:19 +01:00
end
2022-06-09 15:38:02 -04:00
# Identifies version information from a Sparkle appcast.
2021-08-10 18:38:21 -04:00
#
# @param content [String] the text of the Sparkle appcast
# @return [Item, nil]
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
sig { params(content: String).returns(T::Array[Item]) }
def self.items_from_content(content)
require "rexml/document"
xml = Xml.parse_xml(content)
return [] if xml.blank?
2021-06-23 09:27:14 -04:00
# Remove prefixes, so we can reliably identify elements and attributes
xml.root&.each_recursive do |node|
node.prefix = ""
node.attributes.each_attribute do |attribute|
attribute.prefix = ""
end
end
2020-12-12 21:59:04 +01:00
xml.get_elements("//rss//channel//item").filter_map do |item|
2021-06-23 09:27:14 -04:00
enclosure = item.elements["enclosure"]
2020-12-12 21:59:04 +01:00
2021-06-23 09:27:14 -04:00
if enclosure
url = enclosure["url"].presence
short_version = enclosure["shortVersionString"].presence
version = enclosure["version"].presence
os = enclosure["os"].presence
2021-06-23 09:27:14 -04:00
end
title = Xml.element_text(item, "title")
link = Xml.element_text(item, "link")
url ||= link
channel = Xml.element_text(item, "channel")
release_notes_link = Xml.element_text(item, "releaseNotesLink")
short_version ||= Xml.element_text(item, "shortVersionString")
version ||= Xml.element_text(item, "version")
minimum_system_version_text =
Xml.element_text(item, "minimumSystemVersion")&.gsub(/\A\D+|\D+\z/, "")
if minimum_system_version_text.present?
minimum_system_version = begin
MacOSVersion.new(minimum_system_version_text)
rescue MacOSVersion::Error
nil
end
end
pub_date = Xml.element_text(item, "pubDate")&.then do |date_string|
Time.parse(date_string)
rescue ArgumentError
2023-07-17 12:30:12 -07:00
# Omit unparsable strings (e.g. non-English dates)
nil
end
if (match = title&.match(/(\d+(?:\.\d+)*)\s*(\([^)]+\))?\Z/))
short_version ||= match[1]
version ||= match[2]
end
2020-12-18 21:17:55 +01:00
bundle_version = BundleVersion.new(short_version, version) if short_version || version
data = {
2024-03-07 16:20:20 +00:00
title:,
link:,
channel:,
release_notes_link:,
pub_date:,
os:,
url:,
bundle_version:,
minimum_system_version:,
}.compact
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
next if data.empty?
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
# Set a default `pub_date` (for sorting) if one isn't provided
data[:pub_date] ||= Time.new(0)
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
Item.new(**data)
end
2020-12-15 20:26:19 +01:00
end
# Filters out items that aren't suitable for Homebrew.
#
# @param items [Array] appcast items
# @return [Array]
sig { params(items: T::Array[Item]).returns(T::Array[Item]) }
def self.filter_items(items)
items.select do |item|
# Omit items with an explicit `os` value that isn't macOS
next false if item.os && APPCAST_MACOS_STRINGS.none?(item.os)
# Omit items for prerelease macOS versions
next false if item.minimum_system_version&.strip_patch&.prerelease?
true
end.compact
end
# Sorts items from newest to oldest.
#
# @param items [Array] appcast items
# @return [Array]
sig { params(items: T::Array[Item]).returns(T::Array[Item]) }
def self.sort_items(items)
items.sort_by { |item| [item.pub_date, item.bundle_version] }
.reverse
end
2022-06-09 15:38:02 -04:00
# Uses `#items_from_content` to identify versions from the Sparkle
# appcast content or, if a block is provided, passes the content to
# the block to handle matching.
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
#
2022-06-09 15:38:02 -04:00
# @param content [String] the content to check
# @param regex [Regexp, nil] a regex for use in a strategy block
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
# @return [Array]
sig {
params(
content: String,
regex: T.nilable(Regexp),
2023-04-04 22:40:31 -07:00
block: T.nilable(Proc),
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
).returns(T::Array[String])
}
def self.versions_from_content(content, regex = nil, &block)
items = sort_items(filter_items(items_from_content(content)))
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
return [] if items.blank?
item = items.first
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
if block
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
block_return_value = case block.parameters[0]
when [:opt, :item], [:rest], [:req]
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
regex.present? ? yield(item, regex) : yield(item)
when [:opt, :items]
regex.present? ? yield(items, regex) : yield(items)
else
raise "First argument of Sparkle `strategy` block must be `item` or `items`"
end
return Strategy.handle_block_return(block_return_value)
end
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
Sparkle: Pass all items into strategy block 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).
2022-05-31 13:18:40 -04:00
version = T.must(item).bundle_version&.nice_version
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
version.present? ? [version] : []
end
2020-12-19 01:07:56 -05:00
# Checks the content at the URL for new versions.
2022-06-09 15:38:02 -04:00
#
# @param url [String] the URL of the content to check
# @param regex [Regexp, nil] a regex for use in a strategy block
# @return [Hash]
2021-04-04 03:00:34 +02:00
sig {
params(
livecheck: Add support for POST requests livecheck currently doesn't support `POST` requests but it wasn't entirely clear how best to handle that. I initially approached it as a `Post` strategy but unfortunately that would have required us to handle response body parsing (e.g., JSON, XML, etc.) in some fashion. We could borrow some of the logic from related strategies but we would still be stuck having to update `Post` whenever we add a strategy for a new format. Instead, this implements `POST` support by borrowing ideas from the `using: :post` and `data` `url` options found in formulae. This uses a `post_form` option to handle form data and `post_json` to handle JSON data, encoding the hash argument for each into the appropriate format. The presence of either option means that curl will use a `POST` request. With this approach, we can make a `POST` request using any strategy that calls `Strategy::page_headers` or `::page_content` (directly or indirectly) and everything else works the same as usual. The only change needed in related strategies was to pass the options through to the `Strategy` methods. For example, if we need to parse a JSON response from a `POST` request, we add a `post_data` or `post_json` hash to the `livecheck` block `url` and use `strategy :json` with a `strategy` block. This leans on existing patterns that we're already familiar with and shouldn't require any notable maintenance burden when adding new strategies, so it seems like a better approach than a `Post` strategy.
2025-02-04 10:30:16 -05:00
url: String,
regex: T.nilable(Regexp),
unused: T.untyped,
block: T.nilable(Proc),
2021-04-04 03:00:34 +02:00
).returns(T::Hash[Symbol, T.untyped])
}
livecheck: Add support for POST requests livecheck currently doesn't support `POST` requests but it wasn't entirely clear how best to handle that. I initially approached it as a `Post` strategy but unfortunately that would have required us to handle response body parsing (e.g., JSON, XML, etc.) in some fashion. We could borrow some of the logic from related strategies but we would still be stuck having to update `Post` whenever we add a strategy for a new format. Instead, this implements `POST` support by borrowing ideas from the `using: :post` and `data` `url` options found in formulae. This uses a `post_form` option to handle form data and `post_json` to handle JSON data, encoding the hash argument for each into the appropriate format. The presence of either option means that curl will use a `POST` request. With this approach, we can make a `POST` request using any strategy that calls `Strategy::page_headers` or `::page_content` (directly or indirectly) and everything else works the same as usual. The only change needed in related strategies was to pass the options through to the `Strategy` methods. For example, if we need to parse a JSON response from a `POST` request, we add a `post_data` or `post_json` hash to the `livecheck` block `url` and use `strategy :json` with a `strategy` block. This leans on existing patterns that we're already familiar with and shouldn't require any notable maintenance burden when adding new strategies, so it seems like a better approach than a `Post` strategy.
2025-02-04 10:30:16 -05:00
def self.find_versions(url:, regex: nil, **unused, &block)
if regex.present? && block.blank?
2023-02-23 12:23:44 -08:00
raise ArgumentError,
"#{Utils.demodulize(T.must(name))} only supports a regex when using a `strategy` block"
end
2024-03-07 16:20:20 +00:00
match_data = { matches: {}, regex:, url: }
2020-12-12 21:59:04 +01:00
livecheck: Add support for POST requests livecheck currently doesn't support `POST` requests but it wasn't entirely clear how best to handle that. I initially approached it as a `Post` strategy but unfortunately that would have required us to handle response body parsing (e.g., JSON, XML, etc.) in some fashion. We could borrow some of the logic from related strategies but we would still be stuck having to update `Post` whenever we add a strategy for a new format. Instead, this implements `POST` support by borrowing ideas from the `using: :post` and `data` `url` options found in formulae. This uses a `post_form` option to handle form data and `post_json` to handle JSON data, encoding the hash argument for each into the appropriate format. The presence of either option means that curl will use a `POST` request. With this approach, we can make a `POST` request using any strategy that calls `Strategy::page_headers` or `::page_content` (directly or indirectly) and everything else works the same as usual. The only change needed in related strategies was to pass the options through to the `Strategy` methods. For example, if we need to parse a JSON response from a `POST` request, we add a `post_data` or `post_json` hash to the `livecheck` block `url` and use `strategy :json` with a `strategy` block. This leans on existing patterns that we're already familiar with and shouldn't require any notable maintenance burden when adding new strategies, so it seems like a better approach than a `Post` strategy.
2025-02-04 10:30:16 -05:00
match_data.merge!(
Strategy.page_content(
url,
url_options: unused.fetch(:url_options, {}),
),
)
2020-12-24 03:33:14 +01:00
content = match_data.delete(:content)
return match_data if content.blank?
2020-12-19 01:07:56 -05:00
versions_from_content(content, regex, &block).each do |version_text|
Standardize valid strategy block return types Valid `strategy` block return types currently vary between strategies. Some only accept a string whereas others accept a string or array of strings. [`strategy` blocks also accept a `nil` return (to simplify early returns) but this was already standardized across strategies.] While some strategies only identify one version by default (where a string is an appropriate return type), it could be that a strategy block identifies more than one version. In this situation, the strategy would need to be modified to accept (and work with) an array from a `strategy` block. Rather than waiting for this to become a problem, this modifies all strategies to standardize on allowing `strategy` blocks to return a string or array of strings (even if only one of these is currently used in practice). Standardizing valid return types helps to further simplify the mental model for `strategy` blocks and reduce cognitive load. This commit extracts related logic from `#find_versions` into methods like `#versions_from_content`, which is conceptually similar to `PageMatch#page_matches` (renamed to `#versions_from_content` for consistency). This allows us to write tests for the related code without having to make network requests (or stub them) at this point. In general, this also helps to better align the structure of strategies and how the various `#find_versions` methods work with versions. There's still more planned work to be done here but this is a step in the right direction.
2021-08-10 11:09:55 -04:00
match_data[:matches][version_text] = Version.new(version_text)
2020-12-19 01:07:56 -05:00
end
match_data
2020-12-12 21:59:04 +01:00
end
end
end
end
end