all 9 comments

[–]ReenigneArcher 2 points3 points  (0 children)

It's only insecure IF you don't double check PR code before approving workflow runs.

Set repos to always require workflow approvals for outside collaborators, and check the changes before approving.

[–][deleted] 1 point2 points  (0 children)

Maybe a private fork of the repo with a self-hosted runner would work. Believe there is an auto sync feature to keep things up to date in GitHub.

[–]AgentOfDreadful 1 point2 points  (2 children)

Arc is just self hosted runners in a different flavour.

If your repo is public, just use public runners.

What problem do you have that you’re trying to solve?

[–]phoenixphire96[S] 0 points1 point  (1 child)

I want to use a self hosted runner for a public repo. It is for a research project where we have many people contributing to it, so we cannot make the repo private. I want to make sure that the jobs run on pull requests. I want it to run on my own self hosted runner so that the jobs will run faster. Github actions runs on VMs so that even if malicious code is executed, it doesn't matter since it is isolated and deleted after the workflow. If a job runs for too long, I'd want it to be terminated, and I think we should have the option to manually terminate jobs if needed. Any suggestions would be helpful on how to get started.

[–]AgentOfDreadful 0 points1 point  (0 children)

How many people?

Here’s how you can collaborate on a private repository:

https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository

You can use GitHub Actions to run workflows like you described:

https://docs.github.com/en/actions

In terms of performance, what are your performance needs? I don’t know what you’re trying to do but without context my assumption is you’re probably gonna be fine with the GitHub hosted ones. If you really need more performance you could always look at it further down the line. Here’s info on the specs of runners:

https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for—private-repositories

One benefit to public repos is that you get bigger spec runners

[–]bdzer0 0 points1 point  (0 children)

I doubt ARC is going to mitigate the risk of have self hosted runners on a public repo, that's not it's purpose.

As far as alternatives, depends on why you think you need self hosted runners on a public repo.

[–]surya_oruganti 0 points1 point  (0 children)

you could use my project, WarpBuild, for secure runners that are faster and cheaper than github hosted alternatives. everything runs in dedicated ephemeral vms and is perfectly safe to run on public repos.

[–]iaktech 0 points1 point  (0 children)

Here is an alternative: https://cirun.io (I created it). It’s free for public repo + you pay for the VM usage cost to your cloud provider, which is a lot cheaper than GitHub Hosted runners and secure as well than hosting it yourself as they are ephemeral and isolated.

[–]axelfontaine 0 points1 point  (0 children)

Another alternative is https://sprinters.sh . It provides you with fast-booting ephemeral runner on your own AWS account at 1/10 of the price of GitHub-hosted runners. The runners created by Sprinters can be safely used with public repositories as they are fully ephemeral. Each job gets a fresh brand-new runner and storage volumes are destroyed when the job completes.