search

Homebrew / homebrew-portable-ruby

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

Improve bottling workflow #209

Open MikeMcQuaid opened 1 month ago

MikeMcQuaid commented 1 month ago

We have lots of great automation in this repository now 🎉

One thing slowing things down, though, is if we want to build a new Ruby we end up building it (at least) 3 times: 1) in the PR getting it 🟢 2) on master after the PR is merged to get it 🟢 3) in the release workflow to get it 🟢 and uploaded to the release

Ideally the bottles would be built once (maybe twice) and not all three times.

MikeMcQuaid commented 1 month ago

Relatedly: portable-ruby used to have a bottle block and, if it did again, it could likely solve a bunch of these problems.

Bo98 commented 1 month ago

2. on master after the PR is merged to get it 🟢

This was fixed months ago: we don't do this anymore - only a syntax check.

Relatedly: portable-ruby used to have a bottle block

Note that a PR version bump to portable-ruby isn't the same as a release. We've on various occasions in the past updated Portable Ruby and then merged some dependency updates before tagging.

To achieve a bottle block prior to a release, we would need to block any portable-ruby PRs until after all other PRs are merged and then have CI force a rebase.

The historical bottle block was actually attached to the release workflow which is why it was ditched as adding an extra commit at that point is useless as we have git tags.

A possible optimisation if we want is maybe finding the last PR merged and taking the artifact from that (if not too old). A bit messy but theoretically possible.

MikeMcQuaid commented 1 month ago

This was fixed months ago: we don't do this anymore - only a syntax check.

Yup, sorry, missed that, nice work.

To achieve a bottle block prior to a release, we would need to block any portable-ruby PRs until after all other PRs are merged and then have CI force a rebase.

That seems reasonable. Don't need a rebase, though, we can just enable the "branch must be up to date" branch protection.

It seems like there's no real need in the case of the last two releases to rebuild Ruby again in this case when it could have used the existing build here.

A possible optimisation if we want is maybe finding the last PR merged and taking the artifact from that (if not too old). A bit messy but theoretically possible.

Yes, I think this would make a lot of sense.

Bo98 commented 1 month ago

Not what you were asking here, but you may also like: https://github.com/Homebrew/brew/issues/17400. This should somewhat diminish the effect of any slowdown as you can then hit release and not worry how long it takes as the PR will be ready to merge when it is done rather than needing manual steps.