-
-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
bump-cask-pr: bump language checksums in non-running hardware #12241
Conversation
Review period will end on 2021-10-15 at 18:48:06 UTC. |
Review period ended. |
This comment was marked as spam.
This comment was marked as spam.
b744663
to
7dd3b04
Compare
Should be ready to review/merge. Once merged, should hopefully will help avoid separate hardware PRs |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this for now. I'd like to see any future work here go more in this direction: #12786 (comment)
Since I don't have write access, can someone merge the PR? Thanks. |
Thanks again @cho-m! |
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?Related to issue seen in Homebrew/homebrew-cask#112638
The Cask language SHAs in non-running hardware (e.g. ARM for Intel users) are not updated via
bump-cask-pr
.Needs some more testing (and maybe some refactoring) before merge.
EDIT: Does not deal with issue where
bump-cask-pr
fails whencask.language
uses a language block with different key and return value (e.g.en != en-US
like inopenoffice
).The problem is that
cask.language
returns the "called" output of language block whilecask.languages
returns a list of the keys.One solution: run same
cask.language
logic (for this approach, it may be good to refactor so to allowfetch_cask(tmp_cask)
to avoid reloading cask):