Setup "EasyCompile" to allow packaging gem with precompiled binaries

[Edouard-chin]

👋 Thanks for letting me try our tool in this project.

TL;DR This workflow allows with a single click on the GitHub UI to compile/package/test and publish (optionally) a gem with precompiled binaries.

---

This workflow was generated running the easy_compile ci_template command from the EasyCompile tool we are currently developing..

I confirmed that it works on this project https://github.com/Shopify/saturn/actions/runs/19342620213.

---

How does it work

When you'd like to cut a new release, you can head to the GitHub action page, select the workflow and click on "Run workflow".

Once clicked here is what happened:

• We spin up machines on various platforms (MacOS and Linux are configured here). And start the compilation. Since the gem supports multiple ruby versions, we perform the compilation for each ruby minor versions supported (3.2, 3.3, 3.4).
• Once the compilation is done on all platforms, we create a matrix of jobs to test against all ruby versions that we compiled and all platforms.
• If all job passes we package the gem with the precompiled binaries.
• Finally, you have the option to publish the gems on RubyGems by ticking this box (for this to work we need to do a small setup on RubyGems.org and setup trusted publishing).

If you have any questions, please ask :D !

[caution-tape-bot]

👋 It seems that this PR is adding a GitHub Action workflow that looks a lot like a CI step.

If your repository already uses Shopify Build CI or Shipit CD, then please make sure to consider whether you are splitting your CI/CD pipelines and jobs in a way that makes sense and is easy to maintain.

If this workflow change is not introducing a CI step, then feel free to ignore this comment.

For more details and explanation, click to expand...

Shopify Build used to be the required platform for CI at Shopify, but we are now allowing GitHub Actions to be used for this purpose, especially if the repo is using ProdKit for deploys.

But it's not always a good idea to split your CI for a repo or service between different systems at once. We want to make sure that developers think about the potential maintenance costs of maintaining multiple systems before doing so.

For more information, see GitHub Actions on Vault.

Note that this message is based on a simple regex detection, and may not always be accurate. If your action is not a CI step, and is already running on shopify-ubuntu-latest or similar, feel free to ignore this message.

If your repository is intended to become Public later, please use runs-on: shopify-ubuntu-latest for now and ignore the rest of this comment. Though if you need to use Ubuntu 20.04 only, you would need to use runs-on: shopify-ubuntu-20.04. Or runs-on: shopify-ubuntu-latest-2 for Ubuntu 22.04.

---

This comment was added by the GitHubActions::CiStep Caution Tape Bot rule.
View the source of this rule in Services DB

[caution-tape-bot]

👋 It seems that this PR is adding, or editing, a GitHub Action workflow that is not configured to use our custom GitHub Action runners.

For private repositories, the only supported way of running Action workflows is via the custom runners. You can learn more about the supported use cases in our GitHub Actions documentation.

To make sure that your workflow is using these runners you need to add the shopify-ubuntu-latest label to your workflow manifest file, or shopify-core-ubuntu-latest for Core repositories:

runs-on: shopify-ubuntu-latest

If your repository is intended to become Public later, please use runs-on: shopify-ubuntu-latest for now. The custom runners should function the same as ubuntu-latest public runners, though the exact Ubuntu version may vary. Please see the section below for more information about OS selection on premium runners.

If you run into any issues with the custom runners, please reach out in help-eng-infrastructure on Discourse.

Note for OS Versions

The shopify-ubuntu-latest runners can select from two different runner pools, which contain both Ubuntu 20.04 and Ubuntu 22.04 machines. For some workflows, this can cause issues.

To use Ubuntu 20.04 only, you can specify runs-on: shopify-ubuntu-20.04.

To use Ubuntu 22.04 only, you can specify runs-on: shopify-ubuntu-latest-2.

---

This comment was added by the GitHubActions::Workflow Caution Tape Bot rule.
View the source of this rule in Services DB

[Morriar]

Some questions so I can understand better what's happening:

[vinistock]

I wonder if there's a way to run some sort of sanity check on the packaged gem to ensure that the precompiled library is working as expected.

Maybe something like:

• gem install ./packaged_gem.gem
• run some script that just does a quick smoke test

Not necessary for this PR, but I think it would give us an extra layer of guarantees

[vinistock]

If this workflow publishes the gem to rubygems, we may want to call it publish or release.

In fact, it would be really nice to have this workflow be triggered when a release is manually created in the GitHub repo.

[Edouard-chin]

Regarding triggering this workflow when a release is published, I wonder if this is a default we want to add in the generator. The concern I have is that we are going to create a GitHub release but if something happens during the compilation we'd have a release without published gems (or at least until we fix the issues).

I feel like manually triggering the workflow, publishing the gems and then making a GitHub release would make a bit more sense. WDYT ?

[vinistock]

That's totally fair. In fact, we can automatically create the GitHub release from the workflow only after it succeeded.

We have a much more complicated version of this in the Ruby LSP. For Saturn, we can just pass the argument for GitHub's auto-generated release notes and add a .github/release.yml file.

No need to be a part of this PR though! We can do it as a follow up.

[Edouard-chin]

Ah yeah creating a release from the workflow after the gem gets published make sense. I could see this being a sane default when we generate the workflow, although the description of the release may be a bit tricky to infer. I'll open an issue to keep this in mind. Thanks for the suggestion !

[paracycle]

I wonder if there's a way to run some sort of sanity check on the packaged gem to ensure that the precompiled library is working as expected.

Maybe something like:

• gem install ./packaged_gem.gem
• run some script that just does a quick smoke test

Not necessary for this PR, but I think it would give us an extra layer of guarantees

That is the whole point of the test and install jobs in the workflow. The first one runs your tests agains the precompiled gem and the second one checks to see if the precompiled gems can be installed.

[vinistock]

Ah, indeed! I missed the test job. Awesome!

[Edouard-chin]

Thanks for pointing it out Ufuk. That's correct we run the test matrix agains the compiled binaries to make sure there is no issue and also run the gem installation (both for the gem with packaged binaries and the one without).

[Edouard-chin]

I incorporated your feedback in this PR and also made the change in the tool Shopify/cibuildgem#21

If you have any other feedback, happy to take them, otherwise this should be ready to go.