search

Homebrew / homebrew-portable-ruby

🚗 Versions of Ruby that can be installed and run from anywhere on the filesystem.
BSD 2-Clause "Simplified" License
128 stars 43 forks source link

Add livecheck and autobump workflows #203

Closed MikeMcQuaid closed 2 months ago

MikeMcQuaid commented 2 months ago

We're now going to start making Portable Ruby be the newest Ruby version(s) not ending in .0.

For example, we are now on Portable Ruby 3.3.1. We should upgrade to 3.3.2 when it is released.

When 3.4.0 is released, we should not upgrade to it. When 3.4.1 is released: we should.

This would ideally be done with livecheck blocks for all the portable-* formulae in this repository and an autobump workflow that opens PRs for new portable-* versions.

We will only make a new release/upload when we have new Portable Ruby versions (bar critical security vulnerabilities).

CC @Homebrew/core @nandahkrishna @samford @chenrui333 @SMillerDev who may all be interested in helping out here.

samford commented 2 months ago

Just to confirm before creating PR(s) for livecheck blocks:

bevanjkay commented 2 months ago

Is it possible to implement the portable-ruby version restriction in the autobump workflow or should it be handled in the livecheck block?

The throttle dsl should be able to handle this if it's set to 2?

MikeMcQuaid commented 2 months ago
  • Is it possible to implement the portable-ruby version restriction in the autobump workflow or should it be handled in the livecheck block? I tend to prefer for livecheck to return the latest version and for tools that use the information to handle version restriction but it's maybe less of an issue since this isn't core/cask.

I don't feel strongly either way.

  • The aforementioned version restriction only applies to portable-ruby and we simply use the latest version for the other formulae, correct?

Correct, the others should always be latest.

The throttle dsl should be able to handle this if it's set to 2?

Stupid question: would this not mean that we wouldn't get an upgrade to e.g. 3.3.2?

bevanjkay commented 2 months ago

Stupid question: would this not mean that we wouldn't get an upgrade to e.g. 3.3.2?

You would, but I read wrong, and now realise we just want to match anything that doesn't end in .0 - so throttle doesn't work here.

MikeMcQuaid commented 2 months ago

You would, but I read wrong, and now realise we just want to match anything that doesn't end in .0 - so throttle doesn't work here.

Yeh, thought so, thanks for suggesting anyway though 👍🏻 ❤️

samford commented 2 months ago

PR to add livecheck blocks is now up at https://github.com/Homebrew/homebrew-portable-ruby/pull/204.

Bo98 commented 2 months ago

Ah sorry was already working on this last week 😅 and was working on autobump as a push for a no-BrewTestBot-allowed approach (https://github.com/Homebrew/actions/pull/542 was something that helped unblock that).

I've pushed what I had: https://github.com/Homebrew/homebrew-portable-ruby/tree/livecheck but I can drop this for now in favour of the other PR.

Bo98 commented 2 months ago

Something I hadn't looked at yet at all was: do we actually support brew bump(-formula-pr) on resources livechecks yet (not Python)?

Bo98 commented 2 months ago
  • Is it possible to implement the portable-ruby version restriction in the autobump workflow or should it be handled in the livecheck block? I tend to prefer for livecheck to return the latest version and for tools that use the information to handle version restriction but it's maybe less of an issue since this isn't core/cask.

Either approach is possible, but it will likely be easier to use Homebrew/actions/bump-packages with it in the livecheck block.

samford commented 2 months ago

I've pushed what I had: https://github.com/Homebrew/homebrew-portable-ruby/tree/livecheck but I can drop this for now in favour of the other PR.

It looks like your livecheck blocks have some added benefits over my basic PR, so we should integrate some of the changes after some discussion.

MikeMcQuaid commented 2 months ago
  • I didn't use #formula references as I wasn't sure whether homebrew/core will be tapped/available in this environment. If it is, then #formula is the way to go (to align the checks with the core formulae).

It will be yeh 👍🏻

Either approach is possible, but it will likely be easier to use Homebrew/actions/bump-packages with it in the livecheck block.

Ok, good enough reason for me to put this in the livecheck. Should be relatively easy to just make the patch part of the URL be \d*[1-9]

@samford Could you open another PR to further iterate on the livecheck blocks as discussed here based off @Bo98's branch? Thanks ❤️

Bo98 commented 2 months ago

I didn't use #formula references as I wasn't sure whether homebrew/core will be tapped/available in this environment. If it is, then #formula is the way to go (to align the checks with the core formulae).

Good point. If we run in macos-latest it shouldn't be a problem.

  • I was wondering how we would handle openssl version updates. If we're going to do version restriction in livecheck strategy blocks, then your approach makes sense.

Yeah this one is option for discussion but for the sake of avoiding regressions I felt it made sense to use the same strategy to Ruby where we avoid X.Y.0 versions. I know 3.2.0 shipped with a couple issues that we would want to have avoided. The previous branch will always still be supported at this point so seemed like a reasonable approach.

You've opted to check https://raw.githubusercontent.com/ruby/www.ruby-lang.org/HEAD/_data/releases.yml for portable-ruby whereas I'm checking https://www.ruby-lang.org/en/downloads/releases/. We don't want livecheck to surface a new version until the related tarball is available to download, so is there any chance that releases.yml will be updated before the tarball is available? If so, it would probably be better to check ruby-lang.org.

Was simply because it's better machine parseable. I don't have strong preferences so don't mind either way. The tarball link is included in the YML itself so I imagine it should be uploaded at that point as it's a separate server so non-availability is probably not a concern.

It's GitHub Pages so any changes is pushed to the branch is uploaded immediately to the website too.

Related discussion: ruby/www.ruby-lang.org#2066

MikeMcQuaid commented 2 months ago

Yeah this one is option for discussion but for the sake of avoiding regressions I felt it made sense to use the same strategy to Ruby where we avoid X.Y.0 versions. I know 3.2.0 shipped with a couple issues that we would want to have avoided.

Makes sense to me 👍🏻. Maybe we avoid .0 for literally everything in here? Is that overkill?

I don't have strong preferences so don't mind either way.

Let's do whatever homebrew/core does. If we want to change things here: let's change homebrew/core first/too.

Bo98 commented 2 months ago

Maybe we avoid .0 for literally everything in here? Is that overkill?

Possibly. I did it for OpenSSL with the knowledge that the previous version is still supported for at least security updates. This is probably not the case for all of the others.

samford commented 2 months ago

Could you open another PR to further iterate on the livecheck blocks

Will do (edit: https://github.com/Homebrew/homebrew-portable-ruby/pull/206).

Some of these core formulae use a GitHub release asset but don't have a GithubLatest/GithubReleases livecheck block, so I'll create PRs in homebrew/core to update those formulae first to maintain the behavior (edit: https://github.com/Homebrew/homebrew-core/pull/173029).

Should be relatively easy to just make the patch part of the URL be \d*[1-9]

That regex technically wouldn't match 10, 20, etc., so we would have to use a negative lookahead to specifically avoid .0 (e.g., (\d+\.\d+\.(?:(?!0)\d+)(?:\.\d+)*)) if we want to use a regex-only approach instead of a strategy block.

Let's do whatever homebrew/core does. If we want to change things here: let's change homebrew/core first/too.

homebrew/core checks https://www.ruby-lang.org/en/downloads/, since it only needs the latest version (e.g., 3.3.1 for Ruby 3.3). If we want to surface the latest non-X.X.0 version, we have to check a source that provides all versions for a given major/minor and https://www.ruby-lang.org/en/downloads/releases/ is the related page on ruby-lang.org (as used in the PR).

We could update the ruby formula to use the approach in portable-ruby but the downloads page is fine for that formula and we only need the releases page for portable-ruby, so there may be something to be said for keeping the ruby and portable-ruby checks separate.

Bo98 commented 2 months ago

there may be something to be said for keeping the ruby and portable-ruby checks separate.

They will always need to be at least partially different anyway to make it ignore X.Y.0 versions.

MikeMcQuaid commented 2 months ago

Possibly. I did it for OpenSSL with the knowledge that the previous version is still supported for at least security updates. This is probably not the case for all of the others.

Ok, just Ruby and OpenSSL is fine for me.

If we want to surface the latest non-X.X.0 version, we have to check a source that provides all versions for a given major/minor and ruby-lang.org/en/downloads/releases is the related page on ruby-lang.org (as used in the PR).

Perfect, thanks for context. A comment in the block may help here, too, when adding the "no .0" check.

so there may be something to be said for keeping the ruby and portable-ruby checks separate.

You've convinced me 👍🏻

MikeMcQuaid commented 2 months ago

It worked: https://github.com/Homebrew/homebrew-portable-ruby/pull/208! Great work everyone particularly @samford @chenrui333 @Bo98