Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

livecheck: error on invalid url symbol #18622

Merged
merged 2 commits into from
Oct 26, 2024

Conversation

samford
Copy link
Member

@samford samford commented Oct 24, 2024

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes? Here's an example.
  • Have you successfully run brew style with your changes locally?
  • Have you successfully run brew typecheck with your changes locally?
  • Have you successfully run brew tests with your changes locally?

Up to now, we haven't been accounting for #url symbol arguments in livecheck blocks that don't reference a checkable URL. This can either be an invalid symbol (e.g., using the :stable formula symbol in a cask) or a valid symbol where the referenced URL doesn't exist (e.g., using :head when there's no head URL). [Almost all of the valid symbols are required URLs but head is optional.]

Over the years, we've had a handful of slips where we've used :url in formulae (when it's only valid in casks) and :stable in casks (when it's only valid in formulae). In this scenario, livecheck_url_string is nil, so livecheck falls back to #checkable_urls. stable and url are the first checkable URLs for formulae and casks (respectively), so the checks ended up working as expected merely by chance. This isn't obvious in the output and even the debug output looks normal. It only becomes apparent that livecheck isn't working as expected if it iterates through more than one checkable URL before reaching one that works (not the case in those instances).

With that in mind, this adds an error when a #url symbol is used but it doesn't correspond to a checkable URL. This will account for both of the mentioned scenarios (invalid symbols and valid ones referencing a non-existent URL) and prevent livecheck from quietly proceeding in an unexpected manner.


It's worth mentioning that I will also be creating a RuboCop for this in a later PR, so we can catch this with brew style/brew audit (not just at runtime).

I'm currently reworking the livecheck RuboCops to share cops between formulae, resources, and casks. We originally implemented them as FormulaCops before livecheck blocks were available in casks (and later resource blocks) but we didn't have a way of sharing cops at the time. We now have some shared cops, so it's just a matter of migrating the cops to that pattern. I have most of that done (it works for formulae/resources and most casks) but I'm working on writing tests and handling less common cask setups. Once that's done, I'll create a PR for the refactor and added RuboCops.

@samford samford force-pushed the livecheck/error-on-invalid-url-symbol branch from 9eeefc6 to 12ccae8 Compare October 25, 2024 02:45
@samford
Copy link
Member Author

samford commented Oct 25, 2024

This latest push includes the following changes:

  • Added the error to #resource_version, to align it with #latest_version
  • Expanded tests for #livecheck_url_to_string to reach 100% coverage
  • Expanded tests for #checkable_urls to cover everything except branches that shouldn't ever be reached

Copy link
Member

@MikeMcQuaid MikeMcQuaid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @samford, a few thoughts.

Library/Homebrew/livecheck/livecheck.rb Outdated Show resolved Hide resolved
Library/Homebrew/test/dev-cmd/livecheck_spec.rb Outdated Show resolved Hide resolved
Up to now, we haven't been accounting for `#url` symbol arguments in
`livecheck` blocks that don't reference a checkable URL. This can
either be an invalid symbol (e.g., using the `:stable` formula symbol
in a cask) or a valid symbol where the referenced URL doesn't exist
(e.g., using `:head` when there's no `head` URL). [Almost all of the
valid symbols are required URLs but `head` is optional.]

Over the years, we've had a handful of slips where we've used `:url`
in formulae (when it's only valid in casks) and `:stable` in casks
(when it's only valid in formulae). In this scenario,
`livecheck_url_string` is `nil`, so livecheck falls back to
`#checkable_urls`. In this scenario, `stable` and `url` are the first
checkable URLs for formulae and casks (respectively), so the checks
ended up working as expected merely by chance. This isn't obvious in
the output and even the debug output looks normal. It only becomes
apparent that livecheck isn't working as expected if it iterates
through more than one checkable URL before reaching one that works
(not the case in those instances).

With that in mind, this adds an error when a `#url` symbol is used
but it doesn't correspond to a checkable URL. This will account for
both of the mentioned scenarios (invalid symbols and valid ones
referencing a non-existent URL) and prevent livecheck from quietly
proceeding in an unexpected manner.
This expands tests for `#checkable_urls` to cover everything except
branches that shouldn't ever be reached.
@samford samford force-pushed the livecheck/error-on-invalid-url-symbol branch from 12ccae8 to bfdb84f Compare October 25, 2024 14:26
Copy link
Member

@MikeMcQuaid MikeMcQuaid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good thanks @samford! One suggested refactoring.

Library/Homebrew/livecheck/livecheck.rb Show resolved Hide resolved
@MikeMcQuaid MikeMcQuaid merged commit 368d086 into master Oct 26, 2024
27 checks passed
@MikeMcQuaid MikeMcQuaid deleted the livecheck/error-on-invalid-url-symbol branch October 26, 2024 09:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants