- The usage of this in `brew contributions` wasn't correct for a user
with 5 authored commits to homebrew/cask that had been committed by
other people, the numbers would turn out as 5 authored, 5 committed.
- I decided to do this properly by getting the SHAs for author and
committer and determine the differences between the two arrays.
This also accounts for when authored commits are 0, or committed
commits, or both.
- Add tests, because I don't want to fix this a third time!
- Apparently the "verified" parameter in the URL (present when a Cask's
download URL is not the same as its homepage) shouldn't have the
protocol (`https`, `http`) at the front.
- Removing this has happened manually in the past, so here's an
autocorrecting RuboCop for it.
- Part of trying to reduce the number of `Excludes:` we have in our
RuboCop configs.
- The fixes here all seemed reasonable, with some minimal tweaks for
line length and less floatiness. Apart from `test/dev-cmd/bottle_spec.rb`
where RuboCop wanted to do some ridiculously floaty indentation and there
wasn't an obvious alternative place to break the lines, so I opted for
in-line disables instead.
- We want to move away from `Excludes:` in the main `.rubocop.yml` config file
containing full file paths, because it's hard to track whether they're still
necessary or not (and other occurrences in the files that you might
legitimately want to improve are unaccounted for).
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 renames `simple_content` to `content_simple`, which makes the
`content_*` variable name convention more consistent (as is in the
`Xml` strategy tests).
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`).
Set metadata when we load casks from the source API.
Set `@tap_git_head` manually.
Also, allow `auto_update` to receive false.
This is only done for consistency.
Stop double printing the `kext` caveat.
Handle Array elements correctly when substituting
path elements in artifacts. This affected how the
Uninstall Signal keys were evaluated (they are
represented as arrays of arrays).
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`.
I know that we're outside our normal deprecation cycle but: these are
totally broken with the API and it doesn't make sense to support them
only for non-core formulae.
