GITHUB_REF is inconsistent

We’re experiencing an intermittant issue with how the GITHUB_REF environment variable is being set on workflows triggered from a commit within a Pull Request.

Usually, this is set to refs/pull/:prNumber/merge – which we then parse to extract the PR number, to use in constructing the name of a temporary “review app” deployment.

However, sometimes the GITHUB_REF is set to refs/heads/:branchName instead, which breaks our deployment.

This has only started happening fairly recently.

Is this a bug? Or is there a more reliable way of getting the PR number from workflows triggered by pushed commits within pull requests?




You could try obtaning it from the event payload:

PR=`jq -r '.number' $GITHUB_EVENT_PATH`

@frankieroberto ,

When a workflow is triggered by pull_request event, there is an existing property  github.event.number of github context. You can use this property to directly get the PR number, instead of parsing the number from the ref.

- name: get PR number
  run: |
    echo "The PR number is ${{ github.event.number }}"

Generally, when the github_ref is shown as **refs/heads/branchName**, the workflow should not be triggered by pull_request event. You can use the property github.event_name to check the name of the event that triggered the workflow. And you aslo can reference the example printing context information to the log file to print the complete github context of the workflow run.

- name: Print GitHub context
    GITHUB_CONTEXT: ${{ toJson(github) }}
run: |
echo "The event name is ${{ github.event_name }}"

If you workflow indeed is triggered by  pull_request  event but the  github_ref  still is shown as **refs/heads/branchName**, please share your repository with us so that we can check the detailed configurations of the workflow file and the complete github context of the workflow run to analyze the root cause.


Hi @brightran,

Thanks – it looks like


should be a much more reliable way of getting the PR number. I didn’t spot this in the documentation.

Further debugging has showed us that the GITHUB_REF env var is being set to  refs/heads/branchName  only when the workflow is “re-run” from the GitHub user interface. This feels a bit unexpected, as you’d imagine that the workflow would be re-run with the exact same environment, however I can sort-of see why it might be different.  I don’t know if this is a recent change, as I’m sure that re-running failed workflows used to work for us successfully (parsing the GITHUB_REF for the PR number).

Hopefully by using the event context, this issue won’t re-occur for us though.

Thanks again!

Frankie Roberto

1 Like

@frankieroberto ,

Thanks for your reply. 

I also tested to re-run the failed workflow which was triggered by the pull_request event, and get the same result as you mentioned that the github.ref was changed to " refs/heads/branchName" (according to my test and check, it actually was changed to the source branch of the PR, github.head_ref ). This is very strange, I’m not sure why the ref was changed if re-run the workflow. I have report this to the appropriate engineering team, the team will discuss and evaluate this question. If they have any explanation about this, I will notify you in time, and sometimes the appropriate engineers may will directly reply you here.

However, in the github context, the event type and the information about the PR will not be changed, so you can always use the property  github.event.number  to get the correct PR number.


I just found this issue during a discussion about the codecov uploader. That also parses GITHUB_REF to extract the PR number
The problem: The uploader is a script running as such and only has access to the env variables. And GITHUB_EVENT_NUMBER doesn’t show up there
I printed the whole environment and the only related variables are:

  • GITHUB_REF=refs/pull/119/merge
  • GITHUB_REF_NAME=119/merge

Is there any chance to provide $GITHUB_EVENT_NUMBER for PRs?

here you go @Flamefire1 :

- name: Get GITHUB_EVENT_NUMBER in env var
  run: |
     GITHUB_EVENT_NUMBER=$(echo "${{ github.event_name }}")
     echo "Github event number is $GITHUB_EVENT_NUMBER"

Thanks, but it really is an (external) script and as @brightran mentioned that property is the correct one it would be very helpful to have it as an env var built-in just like the other 2
Otherwise everyone using that script would need to remember setting that env bar themselves