Add some `--all` flags we'll eventually migrate to to ensure that we'll
eventually require their usage to read all formulae. Where we need to
do stuff later, add some comments.
- I got frustrated when I fixed the build and test failures for
https://github.com/Homebrew/homebrew-core/pull /95430 only to have the
audit step say it was a pre-release.
- Repology can list versions that are GitHub pre-releases. Pre-release
versions of software are things we don't generally want to ship:
there's an audit specifically for that.
- This fixes `brew bump` to not mark a Repology version as the newest if
the formula's livecheck strategy is `GithubLatest`. If the livecheck
doesn't exist, or its update strategy is something other than
`GithubLatest`, Repology's reported package version is respected.
- The cores are now merged (🎉), so the Linux core tap is
`homebrew-core` not `linuxbrew-core`, everything core should have
switched over, this should be safe to remove.
This allows dispatching the publish workflow via the GitHub UI to have
the exact same behaviour as doing `brew pr-publish`.
ClosesHomebrew/homebrew-core#94704.
Fix a regression from 8b1fcc7c5c.
Only if `version.nil?` is `Version.detect` used, so we can
only use `version.null?` after that. (Otherwise, it's a string.)
```
Error: undefined method `null?' for "X.Y.Z":String
Please report this issue:
https://docs.brew.sh/Troubleshooting
/usr/local/Homebrew/Library/Homebrew/dev-cmd/bump-formula-pr.rb:440:in `check_new_version'
/usr/local/Homebrew/Library/Homebrew/dev-cmd/bump-formula-pr.rb:131:in `bump_formula_pr'
/usr/local/Homebrew/Library/Homebrew/brew.rb:110:in `<main>'
```
Currently, `brew bump-formula-pr` errors out without a proper message
when `--version` isn't specified and the formula's version cannot be parsed
from the URL. We fix this by returning early from `check_new_version` when the
detected version is Version::NULL.
There's a few bits of functionality that Homebrew has changed over the
years, makes sense as a sensible default but some people find really
annoying:
- automatically running `brew update`
- automatically running `brew cleanup`
- automatically upgrading outdated dependents
- automatically reinstalling broken dependents
For each of these: let's improve the documentation of the commands
whose behaviour is changed and the environment variables themselves.
There was a previous discussion about making `brew linkage --test` fail
for unrequested dependencies (#9172). I'm not sure what the outcome of
that was, but it still seems like a good idea to try to help us find
cases of opportunistic linkage as they happen rather than when they
cause CI failures in another PR sometime later.
Let's do this by adding a `--strict` flag to `brew linkage --test`. My
intention is for `brew linkage --test --strict` failures to be warnings
rather than errors in CI, which should mitigate some of the concerns
about doing this that were raised in #9172.
Michael Cho