search

datalad / git-annex

A non-official clone of git-annex established for DataLad purposes. No PRs will be merged, but could be used to test perspective git-annex patches. Official git-annex repository: https://git.kitenet.net/index.cgi/git-annex.git/
14 stars 3 forks source link

setup Mac M1 builds #61

Open yarikoptic opened 3 years ago

yarikoptic commented 3 years ago

re github actions support for it: https://github.com/actions/virtual-environments/issues/2187 . https://github.com/actions/virtual-environments/issues/2187#issuecomment-790507204 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 commented 2 years ago

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 commented 2 years ago

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

yarikoptic commented 2 years ago

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 commented 2 years ago

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

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 commented 2 years ago
  • 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 commented 2 years ago

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

yarikoptic commented 2 years ago

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 commented 2 years ago

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

carlocab commented 2 years ago

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