Getting Forked PR detail from github workflow

[rishi-external]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

I have a github workflow on the PR creation...! but most of the PR are from forked repos, I need a way to find the workflow that is running on which PR and then from that PR I need to get the bae branch of that PR.

I have tried the below
getting PR from issues API and filtering the PRs from the head sha and then finding the workflows ran on that sha
tried also getting the details by using the cehck sum ID

both are not giving the exact PR to workflow relation, is there any way where we an get the forked repo details from the workflow which ran on that RP

[DevFoxxx]

Hi @rishi-external!

The issue you're facing is common when dealing with pull_request events from forks. Instead of trying to reconstruct the relation via APIs and SHAs (which can be ambiguous), you can leverage the github context that is already available inside the runner.

When a workflow is triggered by a pull_request, GitHub populates the github.event.pull_request object. You don't need to fetch it; it's already there!

To get the base branch and the forked repo details, you can use these context variables directly in your steps:

YAML
steps:
  - name: Get PR Details
    run: |
      echo "The Base Branch is: ${{ github.event.pull_request.base.ref }}"
      echo "The Fork Repo is: ${{ github.event.pull_request.head.repo.full_name }}"
      echo "The PR Number is: ${{ github.event.pull_request.number }}"

Why this is better:

• Direct Relation: This context is specific to the exact PR that triggered the run.
• Efficiency: No need for extra API calls or filtering by SHA.
• Forks: github.event.pull_request.head.repo.full_name will correctly point to the forked repository (e.g., user-fork/repo), while base points to your repo.

Keep in mind that if you need to write back to the PR from a fork, you might need to use the pull_request_target event (but be very careful with security/code injection!).

[geektoseek]

Hey! 🦍
so the issue you're facing is actually pretty common with forked repo workflows, took me a while to figure this out too lol
the problem with issues API approach is that it strips out alot of PR specific metadata thats why you're not getting the exact relation. and checksuite ID doesnt give clean 1-to-1 mapping because one commit can exist in multiple PRs technically.
what actually works is using the pull_request event context directly in your workflow, it already has everything you need:
yamlon:
pull_request:

jobs:
details:
runs-on: ubuntu-latest
steps:
- run: |
echo "PR number: ${{ github.event.pull_request.number }}"
echo "Base branch: ${{ github.event.pull_request.base.ref }}"
echo "Fork repo: ${{ github.event.pull_request.head.repo.full_name }}"
echo "Is fork: ${{ github.event.pull_request.head.repo.fork }}"
and if you need to look this up outside the workflow like retroactively finding which PR a run belongs to, do this:
bash# get the head sha from the run first
gh api repos/{owner}/{repo}/actions/runs/{run_id}

then find PR using that sha — use /pulls not issues API

gh api repos/{owner}/{repo}/pulls
--jq '.[] | select(.head.sha == "YOUR_SHA") | {number: .number, base: .base.ref, fork: .head.repo.full_name}'
always use /pulls endpoint instead of issues, trust me it makes a difference
hope this helps!

[DeveloperVaibhav1]

If your workflow is triggered by a pull_request or pull_request_target event, you don’t need to query the Issues API or match the SHA manually. GitHub already exposes the PR information in the workflow context.

You can access the base branch and fork details directly from github.event.pull_request.

Example:

name: PR Info

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  get-pr-info:
    runs-on: ubuntu-latest
    steps:
      - name: Print PR information
        run: |
          echo "PR number: ${{ github.event.pull_request.number }}"
          echo "Base branch: ${{ github.event.pull_request.base.ref }}"
          echo "Head branch: ${{ github.event.pull_request.head.ref }}"
          echo "Head repo: ${{ github.event.pull_request.head.repo.full_name }}"
          echo "Forked repo: ${{ github.event.pull_request.head.repo.fork }}"

Important fields:

• github.event.pull_request.base.ref → base branch of the PR
• github.event.pull_request.head.ref → source branch
• github.event.pull_request.head.repo.full_name → fork repository name
• github.event.pull_request.head.repo.fork → indicates if it’s from a fork

This works for forked PRs as well, as long as the workflow is triggered by the pull_request event. If the workflow is triggered by another event (e.g., workflow_run or push), you may need to pass the PR number explicitly or query the Pull Requests API using the commit SHA.

The GitHub Actions documentation on contexts also explains the available fields:
https://docs.github.com/en/actions/learn-github-actions/contexts#github-context

[DeveloperVaibhav1]

Thanks for the detailed explanation! That makes sense. Using the pull_request event context directly seems like a much cleaner approach than trying to infer the relationship through the Issues API or check suite IDs. The examples showing github.event.pull_request.base.ref and github.event.pull_request.head.repo.full_name are especially helpful for identifying forked PR details. Also appreciate the note about using the /pulls endpoint when mapping a workflow run back to a PR via the head SHA — that clarifies why the Issues API approach wasn’t giving reliable results. I'll give this approach a try in the workflow. Thanks again for sharing the workaround!

…

On Mon, 16 Mar 2026 at 15:22, NAEEM ***@***.***> wrote: Hey! 🦍 so the issue you're facing is actually pretty common with forked repo workflows, took me a while to figure this out too lol the problem with issues API approach is that it strips out alot of PR specific metadata thats why you're not getting the exact relation. and checksuite ID doesnt give clean 1-to-1 mapping because one commit can exist in multiple PRs technically. what actually works is using the pull_request event context directly in your workflow, it already has everything you need: yamlon: pull_request: jobs: details: runs-on: ubuntu-latest steps: - run: | echo "PR number: ${{ github.event.pull_request.number }}" echo "Base branch: ${{ github.event.pull_request.base.ref }}" echo "Fork repo: ${{ github.event.pull_request.head.repo.full_name }}" echo "Is fork: ${{ github.event.pull_request.head.repo.fork }}" and if you need to look this up outside the workflow like retroactively finding which PR a run belongs to, do this: bash# get the head sha from the run first gh api repos/{owner}/{repo}/actions/runs/{run_id} then find PR using that sha — use /pulls not issues API gh api repos/{owner}/{repo}/pulls --jq '.[] | select(.head.sha == "YOUR_SHA") | {number: .number, base: .base.ref, fork: .head.repo.full_name}' always use /pulls endpoint instead of issues, trust me it makes a difference hope this helps! — Reply to this email directly, view it on GitHub <#189728 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BG6IZOFYUBN5TI2N6WVSHB34Q7FGNAVCNFSM6AAAAACWTD55U6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMJVGYYTKOA> . You are receiving this because you commented.Message ID: ***@***.***>