-
Notifications
You must be signed in to change notification settings - Fork 3.4k
ci/workflows: disable github workflows on forks #38791
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
26b4660
to
c258cf3
Compare
8f12dd4
to
6708f02
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea and intent behind this change, but I wonder if there's a more robust way to enforce it (maybe Ariane or some clever reusable action). This might work fine for now, but it seems likely it will get missed/forgotten on some future workflow or the addition of a new job.
@thorn3r Thank you for your input.
I can understand and somewhat agree that this might be overlooked, and there could be another smarter way to do it and fully open to it. However, for now, do you think we could adjust the workflows as a quick win? |
5a465d9
to
d055295
Compare
…l switch Signed-off-by: ishuar <ishansharma887@gmail.com>
d055295
to
914064b
Compare
/test |
Thanks for the improvement @ishuar 🙏 |
Disable GitHub Workflows on Forks by Default
Problem Statement
Currently, GitHub workflows are triggered on forked repositories, resulting in:
While GitHub provides an option to completely or selectively disable Actions on forks, this approach is restrictive and prevents users from using workflows on their forks for legitimate use cases.
Proposed Solution (Explicit Deny over Allow All)
This PR proposes changes to the GitHub workflows to explicitly configure them to run only when the project owner is cilium. By adding this condition, workflows will:
Run only on the cilium/cilium repository by default.
Prevent triggering workflows on forks, saving unnecessary usage and avoiding email spam.
If a fork owner wishes to run workflows, they can still modify the workflow configurations on their fork as needed.
Benefits
Additional Context
Attached below are screenshots of the email notifications and workflow runs triggered on my fork to illustrate the problem being addressed by this PR.