-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
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
question: how to test a cask binary? #18830
Comments
I don’t really see this as necessary, because it really isn’t a problem. Also, with #15603 this will only become less of an issue. That said, I also wouldn’t mind. Lets see other opinions. |
I've floated a simple test balloon in #18879 |
That’s not really the same thing as a test. You’re using |
@vitorgalvao I agree that's not what the binary 'Praat.app/Contents/MacOS/Praat', target: 'praat'
# verify binary
postflight do
cmd = "praat --version"
raise "Cannot run command `#{cmd}`" unless system cmd
end does provide the functionality I proposed above, though: it fails the installation if the Would it be possible to port the |
Might be (especially with #14384), but we’re still not agreed on if this is desirable (waiting for more maintainers to chime in). |
Fair enough. Thanks for linking to the integration issue -- I'll subscribe to that! |
Seems like there isn’t much interest in this. Closing. |
Various casks provide
binary
stanzas to symlink some binary or script within a cask-installed app.Would it be possible or desirable to provide some lightweight functionality to automatically test that the
binary
actually results in a working command?For example, the
praat
cask creates a symlinkIt would be nice to automatically check when the cask is tested or installed that running
praat
actually does run that.../Praat.app/Contents/MacOS/Praat
binary.Because sometimes paths inside apps are changed upstream, and the symlinks would break on installing an updated cask. Or some other stuff happens upstream, and the binary itself no longer works.
Catching this sort of issue during the test builds, and guarding against it during
postflight
might be a good idea.The text was updated successfully, but these errors were encountered: