Closed Bo98 closed 1 day ago
Great idea, thanks @Bo98!
Definitely makes sense to automate this.
What's the difference between updating content in a vendor-install.sh
file vs. updating it in a separate file? Obviously a separate file is easier to implement, so I guess my actual question is where does the update come from? The homebrew-portable-ruby
release workflow? A workflow in this repo? Dependabot?
The
homebrew-portable-ruby
release workflow?
Probably this.
What's the difference between updating content in a
vendor-install.sh
file vs. updating it in a separate file?
Sed replacing ruby_SHA
based on pattern matching of the previous line is a bit messy but not impossible. It gets even more complicated when the minimum macOS changes (i.e. we change el_capitan
to sierra
) as we need to then parse the previous tag information too.
With a separate file you don't need all that at all as you can just do
echo > x86_64-darwin <<<EOS
ruby_TAG=${TAG}
ruby_SHA=${SHA}
EOS
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Verification
brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.Provide a detailed description of the proposed feature
We currently have complex logic in vendor-install to install Portable Ruby: https://github.com/Homebrew/brew/blob/15dc76c5a7a8e51eb465615206666bf7840d0d61/Library/Homebrew/cmd/vendor-install.sh#L15-L66
This is difficult to machine-update. Ideally this should be extracted so that:
Library/Homebrew/vendor/portable-ruby-version
An example system could be a directory (say
Library/Homebrew/utils/portable-ruby-sha256/
or similar) that has filesx86_64-linux
,arm64-darwin
andx86_64-darwin
with contents something like:that we then
source
appropriately incmd/vendor-install.sh
.What is the motivation for the feature?
To automate Portable Ruby releases further so that PRs like https://github.com/Homebrew/brew/pull/17399 could be fully automated (larger 3.3 -> 3.4 updates is out-of-scope for now).
How will the feature be relevant to at least 90% of Homebrew users?
Portable Ruby releases reach users a little faster
What alternatives to the feature have been considered?
Continue updating manually