- There's a TODO on the "someday" list [1] to ensure that `head` Git
URLs always specify a branch.
- So I thought I'd automate this worry by adding an audit.
- Since `resource` block URLs tend to be pinned to SHAs, if indeed
they are Git URLs, this audit only applies to `head` URLs.
[1]: https://github.com/orgs/Homebrew/projects/5?pane=issue&itemId=98789749
The `Cask::Cask` objects in the `SkipConditions` tests don't
interpolate `version` in the `url` strings, so these are technically
unversioned URLs as a result and would be skipped as unversioned. This
updates the URLs accordingly, so they won't trigger the unversioned
skip as a fallback (if the intended test doesn't work as expected).
This is something I discovered while writing a test for a cask that
shouldn't be skipped.
We've been adding `disable!` calls with a future date to casks using
an unsigned app. That implicitly deprecates the cask until it reaches
the disable date, so we've been having to add simple `livecheck`
blocks to casks that use a default check to ensure that livecheck
continues to check them. It was suggested that it would be simpler to
have livecheck not skip casks that have a `disable!` call with a
`because: :unsigned` argument and I agree, so this modifies
`SkipConditions` to add a special case for this scenario.
Formulae, casks, and resources have a `#livecheckable?` method that
indicates whether they contain a `livecheck` block. This is intended
to be read as "has a livecheckable?", not "is livecheckable?" (as
livecheck can find versions for some packages/resources without a
`livecheck` block). Unfortunately, correct understanding of this
method's behavior [outside of documentation] relies on historical
knowledge that few people possess, so this is often confusing to
anyone who hasn't been working on livecheck since 2020.
In the olden days, a "livecheckable" was a Ruby file containing a
`livecheck` block (originally a hash) with a filename that
corresponded to a related formula. The `livecheck` blocks in
livecheckable files were integrated into their respective formulae in
August 2020, so [first-party] livecheckables ceased to exist at that
time. From that point forward, we simply referred to these as
`livecheck` blocks.
With that in mind, this clarifies the situation by replacing
"livecheckable" language. This includes renaming `#livecheckable?` to
`#livecheck_defined?`, replacing usage of "livecheckable" as a noun
with "`livecheck` block", replacing "livecheckable" as a boolean with
"livecheck_defined", and replacing incorrect usage of "livecheckable"
as an adjective with "checkable".
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.
- For some of these I changed `context` to `describe` as it fit better
rather than contriving a "when", "with" or "without", or massively
restructuring the tests.
