How to limit the jobs to particular branches running on self-hosted runners?

[ghost]

Is there a way to add some custom settings on the self-hosted runner instance to reject the jobs triggered from particular branches?

For example, I only want the job to be run on the "main" branch. However someone might create a feature branch, add some dangerous settings to the yaml files in .github/workflows folder to enable the job to run on the feature branch, which is security hole.

Is there way to add some settings in the runner instance to prevent this, or use some other possible solutions to fix the hole? i.e. is it possible to check the branch name on runner instance before running the job and cancel the run if it's not triggered from the valid branches?

Thanks

[fhammerl]

Hi @chengjiaapraamcos, thanks for the feature request. At the moment, there isn't a setting like that, but we're actively investigating similar limitations for runners.

It is recommended to only use self-hosted runners for private repositories. See the docs for more details.

[ghost]

Hi @fhammerl,

Thanks for your reply.

I am using private repo in our organization but I am looking some strategies to control the permission within the team.

For example, we only allow developers to push code / merge pr into "dev" branch, but there's a concern that they might create a new branch including a customized yml file to consume the "prd" runner and push things to prd environment by using this way, then they might delete the feature branch and make the whole thing hard to track.

Any suggestions to prevent this?

[fhammerl]

@chengjiaapraamcos this one is a lengthy read, but in this issue limiting workflow access is discussed in detail. Here you can find some (unofficial and possibly deprecated) workarounds that are maybe close enough to your use case to be useful.

The team's stance is that this is not a runner feature and should instead be implemented server-side. We don't have a public issue tracker for those services as they are open source.

[ethomson]

Hi! This seems like a possibly useful addition. However, suggestions for GitHub Actions functionality belong in the GitHub feedback forum, where the product managers and engineers will be able to review them. This repository is really only focused on the runner application, which is a very small component of GitHub Actions. If you could open this issue there, that would be very helpful for us! 😄

In the meantime, I'm closing this issue here. Thanks again!