Add support for cross-repo runners

[myoung34]

Describe the enhancement

Having an agent per repo is very tedious and frustrating.
It would be nice to have agents that can work across repositories to prevent potentially having hundreds of agents to maintain (with rotating tokens) across hundreds of repos

Code Snippet

n/a

Additional information

n/a

[kubasejdak]

Also, it is hard to synchronize them if they share the same test hardware. Cross-repo runners is a must. Like in GitLab.

[bryanmacfarlane]

Yes! We do have org level runners coming soon along with the ability to edit labels. The combination will allow for more elastic use of runners across your org. Much of the infra is already in place ...

[nodesocket]

Agree, being able to point multiple repos at a single action runner instance is a must.

[Penagwin]

@bryanmacfarlane Is there any chance this will add the ability to run checks on pull requests from forked repositories? Our team currently forks our private repo and merges in, so our pull requests don't trigger any actions.

I know it's for security, but we're managing that through the organization access.

[bryanmacfarlane]

@Penagwin - a big part of org level runners is the ability to manage (route, labels etc.) but also policy and control over things like forks. We would ❤️ your thoughts in this area.

[Penagwin]

I think it'd be great to have org level trusted users - who's pull requests always trigger any actions even from a forked repository, and have repo level trusted forks that are allowed to run checks on pull requests.

Another more nuclear option would be a setting (per-repo) to allow running actions on any pull request to a private repository. It's likely not a good idea to let public repos have that option - and you'll have to handle what happens if somebody changes their repo from private -> public.

Again, because the only members of our organization are employees we can assume any pull request into our repository is non-malicious.

We're excited for labels too as we would like to have a different runner per environment, that way some of our development environments can be in a different part of our network.

[dougparrish]

@bryanmacfarlane

Yes! We do have org level runners coming soon along with the ability to edit labels. The combination will allow for more elastic use of runners across your org. Much of the infra is already in place ...

I have a customer that's interested in org-level runners and offers to be a beta tester. Do you have an ETA for this feature, e.g. 2.21 or 2.22 or farther out? Thanks...

[nodesocket]

👍 also looking for an eta. We have 6 repos, and I really don't want to setup and manage six virtual machines for GitHub action runners.

[GABeech]

As a work-around, the runner config is done in such a way as to allow you to run multiple runners on one machine.

It's still a pain to have to setup individually for each repo, but what i'm doing is creating a folder for each repo actions-runner-repo and running the installation steps there. all the config is contained in that directory and the service is setup based on the directory name.

So, while it's a pain and not as ideal as registering the runner at the org or enterprise level. It's better than running individual machines per repo.

[nodesocket]

@GABeech oh ok, that workaround will be a good solution to keep a single server. Do you know if it's possible to target a particular self-hosted runner based on branch?

if branch === 'master' use runner-production
if branch === 'stage' use runner-stage

[Penagwin]

@nodesocket

There's no support yet for custom labels yet (!?) so that's not currently possible (We want to do the same thing).

The "closest" you can get is if each environment is on a different OS, and use the OS label, but that'd be a really, really stupid workaround.

[bryanmacfarlane]

@Penagwin - custom label support work is currently underway. Org level runner work has also started.

[myoung34]

@bryanmacfarlane The real blocker for us using labels and cross-runner here is also long-term tokens from #244 (we'd want our runners to be automated and that does not align with the current token set up in place).

Is it possible to know if this is going to be released around the same timelines?
Also: are these milestones public? I'd be ok signing an NDA to get more information as its a major production blocker for us to stay fully in Github and not half Github half Gitlab