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

Add action for macOS #54

Open
paulo-ferraz-oliveira opened this issue Jun 25, 2021 · 16 comments
Open

Add action for macOS #54

paulo-ferraz-oliveira opened this issue Jun 25, 2021 · 16 comments
Labels

Comments

@paulo-ferraz-oliveira
Copy link
Collaborator

No description provided.

@wojtekmach
Copy link
Collaborator

wojtekmach commented Jul 2, 2021

This is tricky because while we have OTP images for Linux and Windows, we don't have such for macOS.

We hope to address it in erlang/otp#4487.

In the meantime, I think we could wrap Homebrew. This workflow:

runs-on: macos-10.5
steps:
  - uses: erlef/setup-beam@v1
    with:
      otp-version: 23

would under the hood call:

$ brew install erlang@23

At this moment we can run:

  • $ brew install erlang (OTP 24)
  • $ brew install erlang@23
  • $ brew install erlang@22
  • $ brew install erlang@21

See: https://formulae.brew.sh/formula/erlang

We can't install particular versions, e.g. 23.3.0, and these versions are moving targets, but I think that's OK.

If we're to move forward with this homebrew based solution, it begs the question why not let the users do it themselves, just have them call brew install ... themselves. I think having this in the action would allow nice things like:

strategy:
  fail-fast: false
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
    otp: [24]
    include:
      - os: ubuntu-latest
        otp-version: 23
runs-on: ${{matrix.os}}
steps:
  - uses: erlef/setup-beam@v1
    with:
      otp-version: ${{matrix.otp}}

Furthermore, the action could cache homebrew stuff which would be a nice win for users too.

WDYT?

@starbelly
Copy link
Member

I think that's a good stop-gap solution yes. The limitations are unappealing, but some times something is better than nothing. I'd like to say this should be impetus for the work we've discussed here and there for doing github action builds devoid of Bob, but that needs to be discussed further and I don't think would be any quick solution for it. Then again, maybe starting off such setup with merely mac os builds of erlang is perfect way to start 🤔

I think if we did wedge it in this way, it should be clearly highlighted that we do not support brew, problems you encounter with brew, or use of brew outside of what the action does (which should be opaque). To be clear : "You are free to use brew as it's installed ,but we do not support issues you run into that are not directly related to this action"

In the end, I'm in favor of it so long as it's quicker than setting up a github action based build system.

@jlouis
Copy link

jlouis commented Jul 8, 2021

Just thinking out loud here:

would using https://github.com/kerl/kerl get us to where we want? It can build any Erlang version we want, more or less. So as long as we can provide an image of some kind to start from, builds should be fairly easy to set up and get going. But I don't know if github actions allows us to make images like that for macos.

As for the necessary dependencies, we can probably pull those via homebrew. Which suggests a path:

  • Get a homebrew version to work, first.
  • Add kerl/kerl on top of that.

@paulo-ferraz-oliveira
Copy link
Collaborator Author

I guess the main issue we need to solve is "Where to get pre-compiled stuff from?". As @wojtekmach suggested brew might do the trick (haven't tested how long it would take, though). kerl, on the other hand, involves compilation, which is time-consuming (a LOT!) - unless you know fo some functionality I don't. If we could get those builds (even if with kerl) somewhere online, using it shouldn't be a big problem. Also, I think @starbelly will raise this issue in one of EEF's Build and Packaging meetings, to see if the OTP team could make the images available (they already do, for Windows, and I'm not sure if there's more Windows users than macOS, Erlang-wise).

@wojtekmach
Copy link
Collaborator

"Where to get pre-compiled stuff from?"

Exactly!

I took another stab at upstreaming image building to the OTP team, keeps the fingers crossed! erlang/otp#5036

@paulo-ferraz-oliveira
Copy link
Collaborator Author

That's great @wojtekmach, thanks. After that I'd be glad to merge the macOS in the action.

@jlouis
Copy link

jlouis commented Jul 10, 2021

Yeah, something like kerl would need us to have a place to store the intermediaries. I was of the impression that some of this works off of docker images, but I might have been mistaken.

@starbelly
Copy link
Member

Yeah, something like kerl would need us to have a place to store the intermediaries. I was of the impression that some of this works off of docker images, but I might have been mistaken.

There's some flexibility in not depending on docker images solely. Namely for the case of self hosted runners where you might not be using docker at all (i.e., bare metal, spinning up VMs, etc.).

On a side note and related to this issue I'm terribly curious to see what's being cooked up here by @wojtekmach .

@wojtekmach I saw on twitter where you said this could perhaps be used by this action. Could you elaborate?

@wojtekmach
Copy link
Collaborator

wojtekmach commented Jul 10, 2021

Regarding kerl, I think it is a great tool. As was said, it can build all sorts of OTP versions even across different OSes.

That being said, in my opinion setup-beam should not rely on kerl directly or indirectly.

I think setup-beam should use official OTP builds as much as possible. It already does for Windows. If erlang/otp#5036 lands, we'll make setup-beam use those too. And if OTP has official builds for Linux, I think setup-beam should eventually use those too. This means the Hex team could retire https://github.com/hexpm/bob#erlang-builds which we are keen to. If there were official OTP builds for Linux there most likely would not be a need for Hex to have those builds. Again, kerl really excels at building various OTP versions on various OSes but if we can use official OTP builds, let's do that!

A problem with official OTP images is there is a limited amount of them. For example, there are no official images for OTP 20 for Windows. If erlang/otp#5036 lands, I imagine we'll start building them on OTP 25, maybe OTP 24.1, or something. I think that is actually OK that we won't have all versions of OTP ever for Windows and macOS. I think it is totally reasonable for folks to maybe test their stuff on a couple of versions of OTP for Linux and just one OTP version on Windows/macOS. I don't think a huge build matrix, N OTP * M OS is needed the vast majority of time. Maybe someone needs huge build matrix and maybe setup-beam should accommodate that use case but I personally don't see the need for that.
The fact that there are only so many official OTP builds is going to be less of an issue as the time goes on. Say, 3 years from now, people shouldn't be really use 3+ yr old OTP versions.

@wojtekmach I saw on twitter where you said this could perhaps be used by this action. Could you elaborate?

I think you might be referring to this https://twitter.com/wojtekmach/status/1413614275042676742 so just to clarify, I meant that erlang/otp#5036 should be used by setup-beam. elixir-run could be used but I don't think it should. Not least because it is extremely experimental at the moment. :) I don't have plans for elixir-run to support a wide variety of Erlang+Elixir versions, something that setup-beam would like to have. If there is a new elixir-run version, and that is a big if :), it would use the latest Erlang version + latest Elixir version at that particular point in time, that's it, no backfilling.

@wojtekmach
Copy link
Collaborator

Well, there's another way that elixir-run could be used here but not quite ready to talk about it yet. :)

@Fudoshiki
Copy link

Fudoshiki commented Feb 16, 2022

erlang/otp#5036 merged

@wojtekmach
Copy link
Collaborator

I opened the final PR which would publish the macOS builds on OTP GitHub releases: erlang/otp#5723

@paulo-ferraz-oliveira
Copy link
Collaborator Author

@wojtekmach, I've seen you do stuff on OTP PRs but I'm not sure what's the status there. Are macOS builds available, at this moment? Thanks.

@wojtekmach
Copy link
Collaborator

wojtekmach commented Aug 1, 2022

OTP CI is creating Mac builds. You can see them here:

image

(https://github.com/erlang/otp/actions/runs/2774278710)

These builds are not uploaded to any release though and so are likely only available for a limited time period. erlang/otp#5723 is about automatically uploading these builds to releases but is waiting on a decision to move forward.

@paulo-ferraz-oliveira
Copy link
Collaborator Author

Cool stuff. Thanks for the update. (when stuff's finished, if you don't want/have time/interest in updating this GHA, I might give it a go...)

jgarber623 pushed a commit to CargoSense/dart_sass that referenced this issue Aug 5, 2024
Turns out the underlying setup-beam workflow doesn't support macOS [1].

This change breaks out that OS into its own job whereby we install
Erlang and (some version of) Elixir using Homebrew. I derived this
solution from [2].

🤞🏻 Let's see if it works!

[1] erlef/setup-beam#54
[2] https://github.com/rusterlium/rustler/blob/master/.github/workflows/main.yml
jgarber623 pushed a commit to CargoSense/dart_sass that referenced this issue Aug 5, 2024
Turns out the underlying setup-beam workflow doesn't support macOS [1].

This change breaks out that OS into its own job whereby we ~~install
Erlang and (some version of) Elixir using Homebrew~~ use ASDF to install
the matrix'ed versions of Elixir and Erlang. I (originally) derived this
solution from [2].

🤞🏻 Let's see if it works!

[1] erlef/setup-beam#54
[2] https://github.com/rusterlium/rustler/blob/master/.github/workflows/main.yml

Squashed WIP commits with the following commit messages:

- 0a42b83 YAML 🥴
- 5b9a38a Fix runs-on values
- 95f2fd8 Try using asdf reusable workflow to install Elixir and Erlang
- 1785e90 Update macOS job name
- 3277cef Install Hex
- 5d1d30d Install dependencies in macOS jobs
mcrumm added a commit to CargoSense/dart_sass that referenced this issue Aug 6, 2024
## Description

This PR renames and refactors the project's GitHub Actions CI workflow.
The updated workflow will now run on:

- pushes to `main`,
- pull requests against `main`, and
- by manual invocation via GitHub's UI

Notable changes to the workflow include:

- refactors existing Ubuntu test job
- adds a new macOS test job
- specifies oldest and newest Elixir and Erlang combo in the matrix
- use latest [actions/checkout](https://github.com/actions/checkout)
- sets job name to use matrix values for clarity

The macOS job takes a necessarily different tact for installing Erlang
and Elixir owing to the underlying `erlef/setup-beam` workflow not (yet)
supporting macOS (see erlef/setup-beam#54).
@nathany-copia
Copy link

This would be useful for libraries doing matrix builds to easily ensure they work across common development platforms.

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

No branches or pull requests

6 participants