Skip to content
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

Automated GitHub Action to Prevent PRs from Main Branch #6440

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

shalini-saloni
Copy link

Problem: Sometimes, contributors accidentally submit PRs from the main branch instead of a separate branch.

Why is this a problem?

If a PR is created from main, maintainers can't easily make edits or use automated /fix commands.
It can cause conflicts if multiple PRs are based on the same main branch.
It can lead to issues when merging, since main is usually the production or stable branch.
Proposed Solution:
I implemented a GitHub Actions check that automatically fails a PR if it originates from the main branch. This ensures contributors receive an immediate warning, preventing maintainers from discovering the issue later in the review process. 🚀

@shalini-saloni shalini-saloni requested a review from a team as a code owner February 28, 2025 06:38
Copy link

linux-foundation-easycla bot commented Feb 28, 2025

CLA Signed


The committers listed above are authorized under a signed CLA.

steps:
- name: Fail if PR is from 'main' branch
run: |
if [[ "${{ github.head_ref }}" == "main" ]]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a security expert, but I think there may be a risk of template injection here.
github.head_ref is user-controllable input IIUC. I can't come up with something that would do harm right of the bat, but I can break the workflow by using a branch name like foo";hostname

Might be safer to have it be put in an env variable (outside of run) as to not influence script generation.

Copy link
Member

@svrnm svrnm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While it is best practice indeed to not use the main branch for PRs, I am not worried that much about it:

If a PR is created from main, maintainers can't easily make edits or use automated /fix commands.

That's not correct. the edits are allowed and I can run fix commands, this is only problematic if the PR comes from an ORG and not a USER. (This PR itself is from your main branch and I can see that github allows me to edit it)

It can cause conflicts if multiple PRs are based on the same main branch.

True, but that's then the problem of the contributor to figure out :-)

It can lead to issues when merging, since main is usually the production or stable branch.

That statement makes no sense. If someone forks our repo and creates a PR from their main branch, nothing of that is production/stable.

While I appreciate your time and effort, I don't think adding this workflow is worth the maintanance it will add to the repo

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove this submodule

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants