GitHub Community
-
|
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 |
Beta Was this translation helpful? Give feedback.
Replies: 11 comments 4 replies
-
|
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. 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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
Should absolutely be disabled by default. |
Beta Was this translation helpful? Give feedback.
-
|
It seems you can disable a workflow manually. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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) 🤔. |
Beta Was this translation helpful? Give feedback.
-
|
add a check in the workflow that tests the repository name |
Beta Was this translation helpful? Give feedback.
@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.
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:
Keep all the workflow YAML files in your forked repository, include yours and other people’s.
In your workflows, add the following if conditional for each job.
if: github.repository == ‘jimbob88/Osiris’
In othe…