We need to be able to replicate the `Sparkle` strategy's sorting
and filtering behavior in a related cask audit, so this extracts
the logic into reusable methods.
This also stores `item.minimum_system_version` as a `MacOSVersion`
object (instead of a string), so we can do proper version comparison
(instead of naive string comparison) wherever needed.
Let's start storing `revision` and `pkg_version` for tab runtime
dependencies and use them when available.
When the `revision` is not available, use a conservative approach to
deciding whether dependencies need to be upgrade.
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
Historically, the `Sparkle` strategy's `Item` struct has only
included basic values from the appcast that are commonly useful.
Over time we've selectively added/surfaced more values as we've
encountered outliers that require use of different values in a
`strategy` block.
We now need to use `minimumSystemValue`, so this expands the `Item`
struct to include any appcast value that we could conceivably want
to use in the future. This will hopefully save us from having to make
more modifications to the struct (and related tests) before we can
use a previously-unused value in a `strategy` block.
The previous PR changed how sockets were represented in the JSON
API for formulae and that would cause problems when trying to install
packages with service sockets. This provides backwards compatibility
until all users have upgraded to versions of homebrew that can deserialize
sockets hashes (maybe a couple weeks). Essentially, we store the
socket string when serializing sockets that were originally defined with
only the string parameter otherwise we serialize it to a hash.
This is more in keeping with the other DSL methods and Ruby
convention along with the fact that these socket names are
just used internally by launchd.
This adds support for multiple named sockets to the service DSL.
It also retains backwards compatibility with the previous DSL
where you can declare one socket and it is always just named
Listener by default.
Ever since we started using this at runtime it's been polluting
the backtrace output. This makes it harder to debug errors and
increases the amount of info users have to paste into the box
when filing an issue.
This is a very direct approach. Essentially, we strip out
everything related to the `sorbet-runtime` gem whenever the top
line in the backtrace is unrelated to sorbet-runtime.
The hope is that this will allow errors related to sorbet to
be diagnosed easily while also reducing the backtrace size
for all other types of errors.
Sometimes it is useful to see the full backtrace though.
For those cases, we include the full backtrace when
`--verbose` is passed in and print a warning that the
Sorbet lines have been removed from the backtrace the
first time they are removed.
Note: This requires gems to be set up so that the call to
`Gem.paths.home` works correctly. For that reason, it must
be included after `utils/gems` which is included in
`standalone/load_path` already.
- keep running the command against all os/arch combinations
as the default
- remove todos and deprecations related to changing the behavior
- create constants for os/arch combinations
We're seeing type errors when building formulae that use something
like `xcodebuild ..., "-arch", Hardware::CPU.arch`, since `CPU.arch`
is a symbol. We've been addressing these issues by calling `#to_s` on
the value but there was some talk about simply expanding the type
signatures to accommodate anything that will be cast to a `String`.
There's maybe still an argument to be made for doing string conversion
in formulae but expanding the type signatures will resolve a number of
existing type errors if we simply want to rely on implicit type
casting.
Past that, this also updates the type signature for `BuildError` to
align with the `#system` signature changes, as we receive a type error
otherwise.
- more sensible/performant defaults: default to primary repositories
only for the last year rather than all repositories forever
- allow specifying more than one user at a time
- output the breakdown of contributions without needing `--csv`
- add a space before the `--csv` output
- consolidate some code
- avoid counting authored commits twice, to improve performance
- retry failed GitHub API calls (this happens often when querying all
maintainers)
- stop counting after we find 1000 commits for a given user to avoid
excessive API queries/pagination
These tests were very simple before and now this should result
in more code coverage without affecting test performance.
The only tricky thing was testing the `--missing` option without
actually installing a package using `install_test_formula` because
that is very slow (around 10 seconds on my machine). I ended
up just writing the tab to a plausible keg directory for each
package I wanted to "install". This allows us to test the behavior
while also not increasing CI time by ~20 seconds (though it'd
probably be faster on CI than my local machine).
The existing watchlist test in `dev-cmd/livecheck_spec.rb` will only
pass if the testing environment doesn't contain a livecheck watchlist
file. When a watchlist file is present, it ends up being treated as
empty (formulae and casks aren't available in tests) and produces an
`Invalid usage: No formulae or casks to check` error instead. We don't
have to worry about a watchlist file on CI but it's a potential issue
when running `brew test` locally.
This provides a bogus `HOMEBREW_LIVECHECK_WATCHLIST` value to the
`#brew` call, to ensure that any watchlist file in the testing
environment is not used for this test.
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
Formulae that depend on `node` sometimes contain files that use a
shebang like `#!/usr/bin/env node` and this can lead to issues when
the `node` in a user's environment isn't brewed `node`.
For example, some node modules are compiled when the formula is built
but if the user's `node` is a different major version than brew's
`node`, the differing `NODE_MODULE_VERSION` can produce an error when
certain parts of the application are used. The formula may build and
test fine and the issue may only become apparent when more of the
application is exercised.
This adds a `Language::Node::Shebang` module (borrowing from the
existing Perl and Python examples), which allows us to use
`rewrite_shebang detected_node_shebang, ...` in formulae to address
this type of issue.
- Fix cask info output being incorrect
- Improve some code referring to casks as formulae
- Move livecheck cask fixtures to not shadow existing names
- Adjust the cask tap symlinking logic to make handling outdated
shadowed casks significantly easier
- Fix various flaky tests caused by casks sharding logic
- Prefer longer paths when there's multiple formulae or casks in a tap
with the same name rather than always using the first
