setup Mac M1 builds

[yarikoptic]

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]

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]

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

[yarikoptic]

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]

@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]

• 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]

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

[yarikoptic]

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]

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

[carlocab]

@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.