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

setup Mac M1 builds #61

Open
yarikoptic opened this issue May 28, 2021 · 9 comments
Open

setup Mac M1 builds #61

yarikoptic opened this issue May 28, 2021 · 9 comments
Assignees
Labels

Comments

@yarikoptic
Copy link
Member

re github actions support for it: actions/runner-images#2187 . actions/runner-images#2187 (comment) might be providing a workaround for the self-hosted setup if I got it right. If really needed (I personally has no need and lack time to motivate to work on this) - we could get an M1 and deploy on it.

@yarikoptic
Copy link
Member Author

now we have an M1 cloud instance (thanks to macstadium) and can setup "out of github actions"-build of git-annex on it. For this particular one I guess we could have triggered a build from github action via ssh and just wait for it to complete, and then fetch the artifact. But ideally we should not rely on being able to ssh into the build machine but I don't see how we could avoid that. Ideas @jwodder ?

@jwodder
Copy link
Member

jwodder commented Jan 31, 2022

@yarikoptic Why not set up a self-hosted runner on the machine?

@yarikoptic
Copy link
Member Author

d'oh -- forgot about those, always was avoiding them due to possible security implications. Even though it is a "free" and virtual instance, I would prefer for it to not run possibly malicious outside code since that is where we might build our "non-official" images of git-annex for redistribution. We do run actions on PRs. Is there a way to limit github actions to only specific users thus making it impossible for a PR from non-developers to trigger build of PRed changes on that machine?

@jwodder
Copy link
Member

jwodder commented Jan 31, 2022

@yarikoptic As far as this repository is concerned, there are two different types of PRs:

  • PRs to master: These are run automatically by GitHub Actions. As far as I can tell, the only way to limit runs based on user is to require approval for PRs from outside collaborators (See the options in repository settings under Actions > General > Fork pull request workflows from outside collaborators). However, it is possible to add checks within the workflow to skip any actions based on username; see here.
  • PRs to upstream/master: Runs of these PRs are triggered by a script that checks for new PRs periodically. We can edit this script to impose whatever additional checks we like.

Also note that, in order for the latter and some other things to operate, whatever workflow runs on the self-hosted runner will likely have to support being triggered manually, which can be done by anyone with write access to the repository.

@yarikoptic
Copy link
Member Author

  • However, it is possible to add checks within the workflow to skip any actions based on username; see here.

wouldn't it run workflow AFTER taking a merged into master version of the PR, so malicious user can remove/disable the check first?

  • PRs to master: These are run automatically by GitHub Actions. As far as I can tell, the only way to limit runs based on user is to require approval for PRs from outside collaborators (See the options in repository settings under Actions > General > Fork pull request workflows from outside collaborators)

I think this is the way to go! We even already have "Require approval for first-time contributors".

  • PRs to upstream/master: Runs of these PRs are triggered by a script that checks for new PRs periodically. We can edit this script to impose whatever additional checks we like.

sounds good since that script will run from master so can't have malicious disabling of the checks.

Also note that, in order for the latter and some other things to operate, whatever workflow runs on the self-hosted runner will likely have to support being triggered manually, which can be done by anyone with write access to the repository.

sounds good -- indeed would be nice to trigger a new build in some cases.

Could you please take a stab at setting up such a builder on that instance?

@jwodder
Copy link
Member

jwodder commented Jan 31, 2022

@yarikoptic It turns out that the self-hosted runner isn't available for M1 Macs, just x64.

@yarikoptic
Copy link
Member Author

pity, I have googled myself into https://github.com/mas-cli/m1-github-actions-runner and alike but (all of those) that one seems to run x64 on M1 host, not what we need :-/ so -- may be just ssh'ing and doing the build while simply waiting in action is the only way forward ATM :-/

@jwodder
Copy link
Member

jwodder commented Feb 2, 2022

@yarikoptic It looks like Haskell Stack (which is used to build git-annex) doesn't properly support M1 Macs yet.

@carlocab
Copy link

carlocab commented Feb 9, 2022

@yarikoptic It looks like Haskell Stack (which is used to build git-annex) doesn't properly support M1 Macs yet.

I'm not convinced this is related. We (Homebrew) do not use stack at all to build git-annex, and are still unable to build it.

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

4 participants