I've been doing this personally for a few months and not hit any bugs.
We already do this for `brew tests`.
It will allow us to:
- remove manual type checks from all developer commands (Sorbet does a
better job with these)
- better surface bugs
- better surface type signatures
- get closer to being able to enable this by default for everyone
The PLC and members workshopped and reviewed this based on past AGMs,
especially the 2023 meeting.
This has some small formatting-only changes compared ot the H-G-P version due
to Markdownlint rules on this public repository. I'll port these changes
to the private repo after merging.
The preferred method is opt_bin because that works
with the API and is more portable (works between versions).
Also removed the last example from the docs of `bin/"name"`
from the service block section
- make the CodeCov CI job informational. We don't want red PRs just
because the coverage varies slightly. We still get comments inline
saying where code coverage is met; this is more useful during review
than a single number and failing status
- make the Triage CI job do less: instead of enforcing a time period for
review window, make it only exist to self-approve PRs for merge and
require a maintainer otherwise to review
"System Preferences" has been renamed to "System Settings" on Ventura.
Privacy and security settings have moved, too. This commit makes sure
these changes are reflected. (Some adjustments were already made in
#14092.)
Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
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 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`.
