Homebrew
Add new cask `Growtopia`
Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.
In the following questions <cask> is the token of the cask you're submitting.
After making all changes to a cask, verify:
- [x] The submission is for a stable version or documented exception.
- [x]
brew audit --cask --online <cask>is error-free. - [x]
brew style --fix <cask>reports no offenses.
Additionally, if adding a new cask:
- [x] Named the cask according to the token reference.
- [x] Checked the cask was not already refused.
- [x] Checked the cask is submitted to the correct repo.
- [x]
brew audit --new-cask <cask>worked successfully. - [x]
brew install --cask <cask>worked successfully. - [x]
brew uninstall --cask <cask>worked successfully.
Problems
- [ ] There is a second version displayed within the app that I'm not sure how to write a livecheck for. It's currently
V3.95. I think it can be grabbed from the apple appstore page for it, but trying to figure out how to combine livechecks withcsvversions is making my head spin.
Odd, the Github Action seemingly doesn't have access to the growtopia website, as it both 403s and doesn't get any version returned. It worked when I tested it (multiple times, infact) so i'm not sure what's up here.
I think I know why; it's robots.txt likely blocks the github actions bot from reaching it. Other than that small problem with the checks, there's still the problem of the other version (V3.95) that needs to be solved somehow.
@Adrthegamedev To me it looks like the version provided as a direct download is only the beta and that stable versions are only provided through the Mac App Store?
@Adrthegamedev To me it looks like the version provided as a direct download is only the
betaand that stable versions are only provided through the Mac App Store?
Thing is, it's not available on the Mac App Store, only the iPhone and iOS ones, but that does come into question if the cask should be renamed to "growtopia-beta.rb".
@Adrthegamedev In that case it will be fine as-is. We will just need to sort something out regarding the livecheck.
Our issue here is the configuration of the AWS Elastic Load Balancer. The response headers contain:
Access-Control-Allow-Origin: https://growtopiagame.com
Access-Control-Allow-Origin: https://www.growtopiagame.com
Which prevents livecheck's standard curl configuration from working. Specifying the origin works fine:
curl -LH "Origin: https://growtopiagame.com" https://growtopiagame.com/Growtopia-mac.dmg --output ~/Desktop/Growtopia-mac.dmg
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 112 100 112 0 0 305 0 --:--:-- --:--:-- --:--:-- 306
100 144M 100 144M 0 0 12.7M 0 0:00:11 0:00:11 --:--:-- 15.9M
@bevanjkay Does livecheck have a way for us to pass an origin?
@p-linnane Not at the moment, but in the future we should be able to have a bit more control. @samford has been chipping away at an options API for livecheck.
A trouble I just noticed is that the internal livecheck version doesn't seem to be alphabetically consistent; I originally committed this with a version of "56596", but, if you go download it right now, it downloads as "52720".
curl --location --head --request GET --include https://growtopiagame.com/Growtopia-mac.dmg (what Strategy#page_headers uses internally) works fine for me without an Origin header. This livecheck block also works for me locally, granted the current URL in the location header of the response is https://ubistatic-a.akamaihd.net/0098/52720/Growtopia.dmg, as mentioned above (though this appears to be an upstream issue, not a livecheck issue). If the version doesn't remain consistent, then that would be another problem for livecheck.
The issue for me is that the server gives a 403 (Forbidden) response when the request is made from a blocked IP address range. For example, I tested this on a VPN and received a 403 response even when an Origin header was provided in the request. The 403 response on CI when checking the homepage would suggest to me that our CI machines may also be in a blocked IP address range (it's not uncommon for known cloud providers' servers to also be blocked when VPNs are blocked). It's worth confirming but, if true, it seems like that would be the bigger issue here.
Unless we can come up with a way to work around this, this cask may always fail on CI and I'm not sure how we would handle this type of situation. Our cask maintainers would probably have a better idea about whether there are other casks with this sort of issue (e.g., which have to be merged despite CI failures) and how they're handled.
@samford has been chipping away at an
optionsAPI for livecheck.
For what it's worth, I've had the options feature implemented locally for quite some time but I've been working towards creating PRs for some other changes first, time permitting (I've been busier with work/life/etc. recently). The internal implementation is likely pretty settled but I'll need to discuss approaches to the API (and the tradeoffs) and that may end up taking a bit of time. At the moment, our GSoC project is currently modifying some of livecheck's internals, so I'm trying to be careful about PRs that may create conflicts for our student. That said, there are a handful of casks that explicitly need options and I also have some other livecheck changes planned that depend on it, so it's closer to the top of my to-do list.
Works for me. Just livechecked and then updated to 49124 and it downloaded & installed successfully (though app is not notarized). Can't push to this branch though as I don't have permission.
Given that the app is not signed, we would not be able to accept it into the main repo.
Please consider hosting this in your own Tap and if the developers sign their app in the future we would be happy to consider adding this to homebrew-cask.
Given that the app is not signed, we would not be able to accept it into the main repo.
Thing is, codesign -dv says it's adhoc signed, and not the usual message for if an app is not signed.
@p-linnane I'm not sure if that means it's not signed, but it's certainly an indication of something, and definitely means that this is not the same reason as the roblox casks have been rejected in the past for.
Gatekeeper cannot run checks on an ad-hoc signature, so essentially it is unsigned. If you choose to host this in your own tap you can pass --no-quarantine at install to strip the com.apple.quarantine attribute or run xattr -dr com.apple.quarantine /path/to/app.