search

quicksilver / Quicksilver

Quicksilver Project Source
http://qsapp.com
Apache License 2.0
2.73k stars 285 forks source link

Automatically Create Homebrew-Cask Bump PR on Release #2737

Closed timvisher closed 2 years ago

timvisher commented 2 years ago

This potentially uses GitHub Actions to automatically create a bump PR on the Cask whenever we push a new semantic version tag.

It's currently untested and is meant mainly to ask for feedback on whether it's desired or not.

Thoughts?

Related:

n8henrie commented 2 years ago

Thanks for bringing up the conversation! I've been using homebrew for a long time. I'm a little on the fence about this.

QS has its own update mechanism; aside from the recent <2.0.3 update glitch, it's worked well for a long time. Even if the brew-available version lags, QS should prompt them to update with minimal hassle.

https://github.com/dawidd6/action-homebrew-bump-formula seems to have a pretty low bus factor, and looks like the only commit in the last year was a README update; perhaps that's because it's stable and doesn't need anything, but it would be silly if it became unmaintained in 6 months and we just removed this process (and risk breaking workflows people had built around it in the meantime).

I don't really want to commit to maintaining a tap under the QS org; it looks like one can remove all of the Optional configuration and have it just submit a PR to homebrew/core? Is that your understanding?

Most of the work seems to be automated, which is great, not a huge loss if it doesn't work out, add some convenience for homebrew users if it does. If we merged this and the Actions dependency subsequently breaks or is deprecated, I'd probably recommend ripping it out over fixing it.

Strong feelings either way @skurfer @pjrobertson ?

pjrobertson commented 2 years ago
  1. Homebrew shouldn't replace our built-in updater, that's for sure. We need the ability to send out developer, pre-release and release builds, and a way for non-tech-savvy users to update.
  2. I'm fine with us 'bumping' the homebrew project when we make a new release - like a notification. But as @n8henrie said - we unfortunately don't have the capacity to maintain it ourselves.
  3. If all this PR is doing is making that 'bump', and not expecting anything else, then I'm fine with this being merged.
  4. My only other concern is that we give the homebrew guys too much noise as we create/delete tags.
timvisher commented 2 years ago
  1. Homebrew shouldn't replace our built-in updater, that's for sure.

Definitely zero intention of this! 😅 It's notable that I've been using Quicksilver for so many years and it was only on this latest snag with the auto updater that I even noticed that the Homebrew Cask was at 1.6.0. How long ago was that even released?

Definitely the happy path for receiving updates should still be the auto updater.

The one use case though that that doesn't cover is new machine set ups. I tend to use brew install <cask> to get all my software installed on a new machine and Quicksilver installing the non-latest version is just a bit of a pain. Something that automatically issues requests to bump the version as new releases are made could help with that, I think.

  1. We need the ability to send out developer, pre-release and release builds

Again I'm not an expert but my understanding of the tech here is that this will only get triggered when the releases/latest target changes or, in other words, when a new 'public release' happens. developer/pre-release builds etc. shouldn't update that. That's something I'd be happy to validate.

  1. My only other concern is that we give the homebrew guys too much noise as we create/delete tags.

I don't think there should be a ton of noise here so long as we're not constantly updating what releases/latest points to. My only concern is how the action would behave if there's several releases in quick succession. The Homebrew tooling is able to notice when there's already a PR in place and rejects making a new one but I'm not sure if it's able to edit that PR. So if you wanted to do several releases in a row it might require going to the Homebrew Cask PR and closing it or something. This is all stuff I intend to explore if there's appetite for the overall change, which it sounds like there is.

That all sound good?

n8henrie commented 2 years ago

SGTM

I don't really want to commit to maintaining a tap under the QS org; it looks like one can remove all of the Optional configuration and have it just submit a PR to homebrew/core? Is that your understanding?

@timvisher if confirmed, would you mind removing all the optional config, and I'll figure out adding an access token.

custom GitHub access token with the 'public_repo' and 'workflow' scopes

I don't see an option for access tokens at the organization level; should this be an access token generated from my personal account? (https://github.com/settings/tokens)

n8henrie commented 2 years ago

bump @timvisher

timvisher commented 2 years ago

@n8henrie Thanks for the bump. This is in my todo list and I do really want to get to it but I've got a lot going on at the moment. If you'd like we can just close it and I'll reopen if I find a few spare cycles or we can leave it open. Sorry it's taking me so long. :\

n8henrie commented 2 years ago

No worries, thanks for the quick response. Let's close for now and reopen when you're ready.