fix(gitify): add preflight steps to reduce errors during brew upgrade

[setchy]

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 any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused.
• Checked the cask is submitted to the correct repo.
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

Appreciate any wisdom from the maintainers. 🙏

We've been seeing the error documented at gitify-app/gitify#918 when performing a brew upgrade for Gitify.

My most recent theory is it's due to the previous Gitify.app is left running which causes the resource not found issue.

[bevanjkay]

This is a known and somewhat expected issue. We have changed the way the uninstall quit stanzas work so that they do not fire on brew upgrade. This is because it may not be expected for an app to be forcibly closed resulting in the loss of unsaved work.
In the case of gitify it may be safe to forcibly close this, but it is likely best to instruct the user to restart the app themselves after an upgrade. They would have had to have reopened it anyway.

The other option which was discussed to a certain level, was adding an option to uninstall quit that does fire on brew upgrade in cases where it is known to be safe.

[setchy]

Thanks for the speedy reply, @bevanjkay 🙇

In the case of Gitify, closing the app will be fine since we're always pulling state from GitHub.

If force quiting the app helps remove/reduce the unexpected errors, then that's a win imho

I've also added a postflight script to relaunch the app.

The other option which was discussed to a certain level, was adding an option to uninstall quit that does fire on brew upgrade in cases where it is known to be safe.

Nice! Yes, this would be cleaner for cask maintainers to opt-in where safe. Even better, if the app could be relaunched afterwards, too

[bevanjkay]

I'm okay with this in principle, but I think we would be better off adjusting the uninstall quit dsl to allow for this use case. If we add a preflight block here that closes the app, it sets a precedent to customise this in other casks. We try to avoid preflight/postflight blocks as much as possible and are looking to remove them. We should file an issue at github.com/homebrew/brew to track the idea of allowing certain apps to be quit forcibly first.

[setchy]

Homebrew/brew#17247

[setchy]

While discussion on DSL changes continues on Homebrew/brew#17247, would it be possible to move forward with this fix @bevanjkay.

Happy to pivot once the alternate route is available

[bevanjkay]

Yeah I guess it's the best option for now. I was hoping for a second opinion from another maintainer, I'll see if I can get one.

[setchy]

@bevanjkay - we're planning a new release of Gitify this week. Do you think this can proceed in its current form?