Stop github actions running on a fork

[jimbob88]

Hey everyone,

I have a fork of danielkrupinski\Osiris on my Github, here and recently Daniel pushed a pull request which added a new action for testing the building of Osiris. Personally, I don’t want to have these actions running on my Fork, is there an easy way to freeze actions so as to stop my fork using up my Action time… By the way, I expect the main.yml to updated quite frequently on his master branch soon as the pull request mentions adding things such as artifacting + automatic release uploading! If I just delete main.yml the pull request, which is currrently automatic, will always conflict!

Also, is it possible to have my own github action, instead of his, because with my releases, I build for AVX, AVX2, IA32 & SSE2, and I have a main.yml and obviously this would conflict with my automatic pull system, as it did when I first had these github actions and having this main.yml would make it so I would have to go through the round-about route of allowing his main.yml to update (i.e. delete my main.yml, pushing his pull request, adding my custom main.yml back), feel free to point me in the right direction, if I am wrong here though!

Thanks in advance,

Jim

[BrightRan]

@jimbob88 ,

If you do not want any workflows run on your repository, you can navigate to Settings > Actions > Actions permissions to Disable Actions for this repository.

disable_actions.PNG1001×426 27.2 KB

However, as you mentioned, you may need to run some of yourself workflows, so this may be not a perfect way. And we have no methods to allow us to tell the PRs only merge the files we want and do not merge the files we do not want.

As a workaround, maybe you can try this:

1. Keep all the workflow YAML files in your forked repository, include yours and other people’s.

2. In your workflows, add the following if conditional for each job.

   if: github.repository == ‘jimbob88/Osiris’

3. In other workflows, add the following if conditional for each job.

   if: github.repository != ‘jimbob88/Osiris’

The property github.repository of the github context can return name of the repository where the workflow is running. Of course, you also need to merge and sync the same configurations to the original repository.

This is the only way I can think of, hope it can help you.

[keeganwitt]

This worked for my use case, where I only forked a repo to make a PR against the upstream repo. I have no interest in running the scheduled junk they run upstream.

But it seems like having it disabled really ought to be the default. It’s that way for other systems, like Travis. I know the permissions model is different there, but still, it shows folks are fine with having to check a box before their CI config runs.

[rhaschke]

I fully agree. You should actively opt-in for github actions to run, particularly on forks! Currently I’m struggling with a GHA workflow that is scheduled for a nightly run … and failing, causing many spurious email notifications for a repo that I just forked.
Disabling actions completely isn’t an option for me, because I do want to validate my stuff before filing a PR against the main repo.

[jedwards1211]

I landed here because I made a PR to babel and I got an email about an action failing. I thought my PR had failed, but when I went to it I didn’t see any CI failures…I was confused for a moment before I realized that the github actions were running separately in my fork, and one was failing to publish to their Verdaccio registry because obviously I don’t have permissions.

My reaction was:

• Whoa, this is a big surprise compared to how all other CI platforms work
• This probably isn’t what the maintainers wanted to happen either
• Did this count against a quota on my account, accidentally?
• This feels like a security exploit waiting to happen

Should absolutely be disabled by default.

[josecelano]

It seems you can disable a workflow manually.

[pombredanne]

FWIW I have 5K+ repos. I cannot go through each of them one by one.... I now found out that there are random jobs running on some of my forks... actions/runner#2063

[krs0]

Default should be not to run these things. I only found out months later that Scheduled actions were running daily for ~1h on a repo I forked. Complete waste of resources.

[rickstaa]

Is there a way to create a feature request for changing the default behaviour to opt-in instead of opt-out 🤔? Many people use @BrightRan's workaround (see https://github.com/search?q=if%3A+github.repository+%3D%3D+%27&type=code), but in most cases, I encounter, only a small group of people (core maintainers) want to enable actions on their forks. In contrast, the majority (i.e. the primary users) want them to be disabled. Because of this, I think the opt-in behaviour suggested by others above makes more sense.

[pombredanne]

There is another issue: there is a cost attached to running these non-desired jobs : https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions

Could it be that GitHub's interest is to have user use and eventually pay for more of these?

[rickstaa]

I just noticed that GitHub already implemented this feature, but it is not clearly documented yet. Currently, when you fork a repository containing actions, you first have to opt-in for these actions to run. You will get a prompt for this the first time you open the action tab.

[laurent22]

The problem is that people don't really know what they are going to enable or disable, so as far as I can see many click that big green button anyway, because "why not". So this is a good solution for people who fork and really don't want to run any action, but a bad solution for repo owner who don't want any fork to trigger their workflows.

[rickstaa]

The problem is that people don't really know what they are going to enable or disable, so as far as I can see many click that big green button anyway, because "why not". So this is a good solution for people who fork and really don't want to run any action, but a bad solution for repo owner who don't want any fork to trigger their workflows.

If I recall it correctly, the prompt only shows up when users click on the actions tab after forking, not during the forking pipeline 🤔. You can test this behaviour if you like. I, however, agree with you that the workflow can be improved. I think having an option to only enable certain actions instead of enabling them all would be an improvement.

[laurent22]

Not sure exactly how it works, but at the moment we're being spammed by people forking the repo, which in turns trigger the CLA workflow, and that sends notifications to all the previous contributors.

I've tried changing the workflows so that they run only from our repo with this change but that didn't help, and we're still being spammed.

I feel the solution would be some switch to say we only accept workflows that originate from specific repositories. I don't see the point of our workflows running for other people's forks.

[rickstaa]

Not sure exactly how it works, but at the moment we're being spammed by people forking the repo, which in turns trigger the CLA workflow, and that sends notifications to all the previous contributors.

I've tried changing the workflows so that they run only from our repo with this change but that didn't help, and we're still being spammed.

I feel the solution would be some switch to say we only accept workflows that originate from specific repositories. I don't see the point of our workflows running for other people's forks.

I quickly tested it out. It seems that the behaviour I described is correct:

Meaning that the spam you receive is only from the people who forked the repository before GitHub implemented the opt-in behaviour. The condition you use in your action should disable the fork runs for these people. If that doesn't work, you can maybe try using environmental variables (see https://github.com/sdr-enthusiasts/plane-alert-db/blob/321424922c3b00959d99f30e53ec36ad45609e62/.github/workflows/create_db_derivatives.yaml#L18) 🤔.

[maphew]

I just noticed that GitHub already implemented this feature, but it is not clearly documented yet. Currently, when you fork a repository containing actions, you first have to opt-in for these actions to run. You will get a prompt for this the first time you open the action tab.

I did not get this prompt. Did something change in the year since this post?

[Vyvy-vi]

add a check in the workflow that tests the repository name

[jonian]

Still no way to disable upstream actions and allow only the actions in your fork to run. Adding checks does not make sense, you can just delete those actions.

Why not provide an option where you select only the actions that you want to run in your repo.

[christoferd]

How can I disable workflows automatically running in Github?

This has not been answered for the latest version of the UI :-(

[fuzzykiller]

Disabling actions altogether didn’t work for me. For a scheduled job (this one, but in my now-deleted fork) I still received notifications, now telling me “Close stale PRs: All jobs were cancelled”.