Force feature branch on PR

Is there a possibility to force the creation of a feature branch?

I tried something like this:

---
name: Validate PR

on: [ pull_request ]

jobs:
  ValidateBranch:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/master' || github.ref == 'refs/heads/main'
    
    steps:
      - name: Mark as failed
        run: |
          echo "You are not allowed to directly push into $(echo ${GITHUB_REF##*/}). Please create a feature branch and update your PR accordingly."
          exit 1
        
  Foo:
    runs-on: ubuntu-latest
    needs: [ValidateBranch]

    steps:
      - name: Foo
        run: echo "Hello World"

But this doesn’t seem to work. Instead, all jobs are skipped and the action appears to finish successfully.

I want to mark the action/workflow as failed and display the information from the 1st step within the PR.

What if you remove the first line ---?
What is the actual value of github.ref?
The workflow trigger is pull_request, shouldn’t it be on: push?
Did you test it with a PR in the same repo or a fork?

Hi,

What if you remove the first line --- ?

That’s the YAML standard. It doesn’t matter if it’s there or not. Old habits.

What is the actual value of github.ref ?

According to the documentation, it’s “The branch or tag ref that triggered the workflow run.”.

The workflow trigger is pull_request, shouldn’t it be on: push?

No. I want to force it for PRs, not for direct pushes.

Did you test it with a PR in the same repo or a fork?

In the repo itself.

You haven’t checkout anything. Assuming you want to checkout the PR branch you should:

    - name: Checkout
      uses: actions/checkout@v2
      with:
        ref: ${{github.event.pull_request.head.ref}}
        repository: ${{github.event.pull_request.head.repo.full_name}}

What is the actual value of github.ref ?

According to the documentation, it’s “The branch or tag ref that triggered the workflow run.”.

I believe that Simran-B meant you could echo it or something and check the value.


In your workflow is there a reason you’re doing all the extra variable and echo handling?

- echo "You are not allowed to directly push into $(echo ${GITHUB_REF##*/}). Please create a feature branch and update your PR accordingly."
+ echo "You are not allowed to directly push into ${GITHUB_REF##*/}. Please create a feature branch and update your PR accordingly."

In the end a PR is a PR, aside from “best practice” do you really need to care what branch in a fork it originates from? (That’s not to discourage you, it a good experiment, but I’m curious if it’s really relevant in the end.)

Well, it’s more a nice to have, than a must have. In the contribution guidelines, we ask people to create a separate Branch and I know, that people don’t read it. But since there’s more to know, they should. So declining PRs that don’t fit will make them read it (i hope).

But I wonder, if this check really needs a checkout? In the original Workflow, there are multiple jobs that run a checkout. And since this check doesn’t involve anything within the repo itself, i thought, a checkout isn’t required here.

To summarize this up:

I want to check, if the branch in the PR is master/main or not. If it is, I want to let the whole workflow fail and display the problem in the PR.

Well ok just do your if statement against ${{github.event.pull_request.head.ref}}

Right, seen it in the spec. Haven’t seen it in any workflow though. As GitHub Actions has no full YAML parser (no anchor support for instance), I thought that it might cause some weird behavior. I confused it with ... though.

I’m pretty confused… Every pull request is backed by a branch. Most users won’t have write access to the repository, thus they can’t push feature branches to the very repository. If they click on the pencil icon in the GitHub web UI to edit a file, the repo is forked in the background and the default branch name will be patch-{number}. The head branch in their forked repo could be named main or master, but does it matter?

Contributors with write access can push feature branches to the original repository, or push commits onto master/main directly. If you disallow direct pushes to the default branch with branch protection, what other way would there be to create a PR which with main/master as branch?

You can’t possibly create a PR with both base and head branch being the same. They can have the same name as long as they are in two different repos, but the same repo? In order to create a PR you got to upload the commits to a remote repository, and if that’s the original repo, that would mean to directly push commits from your local working copy branch to the remote branch - for which you can’t open a PR anymore, because the old base is gone and now equal to the former head.

Am I totally missing something here? Do you want users to create PR against base branches other than main/master?