Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve bottling workflow #209

Open
MikeMcQuaid opened this issue May 31, 2024 · 4 comments
Open

Improve bottling workflow #209

MikeMcQuaid opened this issue May 31, 2024 · 4 comments

Comments

@MikeMcQuaid
Copy link
Member

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
Copy link
Member Author

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

@Bo98
Copy link
Member

Bo98 commented May 31, 2024

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
Copy link
Member Author

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
Copy link
Member

Bo98 commented May 31, 2024

Not what you were asking here, but you may also like: Homebrew/brew#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants