GitHub Action pull_request attribute empty in workflow_run event object for PR from forked repo

[Thomas-Boi]

---

2024-03-06 EDIT

Issue not solved. Workarounds are available below. I'll unmark my answer since others have come up with other solutions. This will also hopefully get GitHub to work on a native fix for this problem, which is needed to do tasks like commenting on a PR from a forked repo.

-----

Hello there,

I notice a weird issue with the workflow_run event object when it involves a PR from a forked repo.

Context:
- I have a workflow_run workflow that will run after a specific pull_request workflow
- I wanted to find the PR number of the pull_request using the github.event context.

Problem:
-If the PR is from a local branch inside the repo, the pull_request attribute of the github.event context is populated

image1087×834 67.1 KB

Link to Action log: Merge pull request #24 from Thomas-Boi/develop · Thomas-Boi/devicon@d0884eb · GitHub

-If the PR is from a forked branch outside the repo, the pull_request attribute of the github.event context is empty

(no picture because GitHub prevented me from posting more than one picture as a new user)

Link to Action log: Merge pull request #24 from Thomas-Boi/develop · Thomas-Boi/devicon@d0884eb · GitHub

This makes it unstable to find the PR number using the github.event attribute. I wonder if this is intentional for security reasons.

Code and Replication:
PR workflow (example of what I’m trying to do)

name: Peek Icons
on:
  pull_request:
      types: [labeled]
jobs:
  build:
    name: Peek Icons
    runs-on: windows-2019
    env:
      PR_NUMBER: ${{ github.event.number }}
    steps:
        - run: echo $PR_NUMBER 

workflow_run workflow (example of what I’m trying to do)

name: Post the screenshots into a comment from Peek Icons workflow
on:
  workflow_run:
    workflows: ["Peek Icons"]
    types: 
      - completed
jobs:
  post_screenshots_in_comment:
    name: Post the screenshot
    runs-on: ubuntu-18.0
    env:
      EVENT_OBJ:  ${{ toJson(github.event) }}
    steps:
        - run: echo $EVENT_OBJ

To replicate this issue:
- Create a repo and add these workflows in the master branch.
- Fork that repo
- Create a branch in the original repo. Add any change to it, push, then open a PR into master.
- This will trigger the pull_request workflow and the workflow_run workflow afterwards.
- View the log in the Actions tab
- Create a branch in the forked repo. Add any change to it, push, then open a PR into the original branch.
- View the log in the Actions tab
- This will trigger the pull_request workflow and the workflow_run workflow afterwards

[fabianofernandeszup]

I have the same problem. I’ve done other tests and I think the problem is the fork.
When the Pull request comes from a fork repository, the PR object comes empty everywhere in the workflow.
I tried in several ways, but I couldn’t relate the pull_request number to that execution, workflow, suite, etc.

Did you have any success after this post?

[Thomas-Boi]

Hi,

Yes I did. When I figured that I can’t get a PR number reliably from the workflow_run workflow, I decided to get it from the trigger workflow instead.

Details:

• Say workflow A (which has a pull_request event) will triggers workflow B (which has a workflow_run event)
• In workflow A, I get the PR number from the github.event. This is reliable for pull_request events. I then save that number into a file and upload it as an artifact.

      - name: Save the PR number in an artifact
        shell: bash
        env:
          PR_NUM: ${{ github.event.number }}
        run: echo $PR_NUM > pr_num.txt
  - name: Upload the PR number
    uses: actions/upload-artifact@v2
    with:
      name: pr_num
      path: ./pr_num.txt

• In workflow B, I get the artifact and the PR number inside from the workflow A using the following GitHub Apps:

      - name: Download workflow artifact
        uses: dawidd6/[email protected]
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          workflow: peek_icons.yml
          run_id: ${{ github.event.workflow_run.id }}
  - name: Read the pr_num file
    id: pr_num_reader
    uses: juliangruber/[email protected]
    with:
      path: ./pr_num/pr_num.txt

This method has worked for me ever since. You can check out the files here:

• Trigger workflow
• workflow_run workflow

[nomeata]

This is also how it is done on the official github blog that talks about security: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/.

But isn’t it actually rather insecure! Someone can easily create a PR that writes a wrong PR number in the artifact. Depending on what you do with that number, this can be annoying to dangerous.

It’s really werid that this rather important use-case for workflow_run doesn’t work out of the box.

[polarathene]

This is also how it is done on the official github blog that talks about security

For context, the blog post was published a little over a month later.

It's outdated in the sense that it relied on scripts as the earlier versions of official actions/download-artifact was lacking the capability to download archives across separate workflow runs (I think that became available early 2024?). That's where dawidd6/action-download-artifact was often chosen instead of the script as a terser choice until official support landed.

---

But isn’t it actually rather insecure! Someone can easily create a PR that writes a wrong PR number in the artifact. Depending on what you do with that number, this can be annoying to dangerous.

First-time contributors require approval before the workflows are run, but if you are doing something with untrusted input where even the wrong PR number is a concern, you can enforce always requiring approval for pull_request runs for non-collaborators.

When you only need PR metadata like the number, you can avoid relying on passing information through pull_request and instead use gh pr view to query this information securely 💪

If you do need to pass other information, you could use the file/ENV approach with untrusted data the PR author can modify if validation is sufficient to trust it. Or with care, pull_request_target + workflow_call.

All three approaches are documented for reference here: docker-mailserver/docker-mailserver#4267 (comment)

[danepowell]

This issue persists, and is still not even documented by GitHub. It should not be considered “solved”, the solution provided above is merely a workaround.

An alternative (perhaps easier and more comprehensive) workaround is to use the Get Workflow Origin action.

It’s a bit of a kludge: it works around this issue by enumerating all PRs and finding the matching SHA for the workflow_run. But it works and requires minimal extra effort.

See my implementation of this plugin for reference.

[alltilla]

I have read that there were some improvements around this. Has anyone checked out the new cross-run artifact download? https://github.blog/2024-02-12-get-started-with-v4-of-github-actions-artifacts/#cross-run-or-repository-downloads

Edit:
Now that I check it again, this might not even be related to this problem, sorry for the noise.

[davidlj95]

It definitely helps downloading artifacts by using the run-id only:

https://github.com/davidlj95/ngx/blob/85acbb62af57248d6b4421dd952af0939a86b3e1/.github/workflows/pull-request-completed.yml#L34-L41

Much shorter / clearer than original way posted in GitHub Security Lab post

However, if you want to do something else than downloading an artifact (like commenting on a PR), I think the issue still persists 😢

[polarathene]

I recently went over the current options and documented them all here: docker-mailserver/docker-mailserver#4267 (comment)

If you don't need to pass anything else across workflows via artifacts, and you only need common metadata like the PR number you can do this quite easily.

@davidlj95 I saw in another comment that you hit a secondry rate limit with the REST API approach. The gh pr view approach below should minimize that risk I think, as I've only observed it to increment the graphql limit usage by 1 (a similar workflow with the PR comment raised the core limit used by 7).

---

Example

Here's your referenced workflow adapted:

name: Pull request completed

on:
  workflow_run:
    workflows: [Pull request]
    types:
      - completed

# `gh pr view` needs `read` for both contents + pull-requests
# `marocchino/sticky-pull-request-comment` needs `pull-requests: write`
permissions:
  contents: read
  pull-requests: write

env:
  BUNDLE_SIZE_ARTIFACT_NAME_SUFFIX: bundle-size
  BUNDLE_SIZE_COMMENT_ID_PREFIX: bundle-size-comment

jobs:
  load-config:
  # ...
  bundle-size-pr-comment:
    name: Bundle size - PR comment - Angular ${{ matrix.cli-version-alias }}
    needs: load-config
    if: github.event.workflow_run.event == 'pull_request' &&
      github.event.workflow_run.conclusion == 'success'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    strategy:
      matrix:
        cli-version-alias: ${{ fromJSON(needs.load-config.outputs.example-apps-version-aliases) }}
    steps:
      - name: Download bundle size analysis results
        uses: actions/download-artifact@v4
        with:
          name: ngx-meta-${{ env.BUNDLE_SIZE_ARTIFACT_NAME_SUFFIX }}-${{ matrix.cli-version-alias }}
          # These two are required for downloading artifacts from a different workflow run:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          run-id: ${{ github.event.workflow_run.id }}

      - name: 'Get PR number'
        id: pr-context
        env:
          # The GH CLI uses this ENV for providing an auth token:
          GH_TOKEN: ${{ github.token }}
          PR_TARGET_REPO: ${{ github.repository }}
          PR_BRANCH: |-
            ${{
              (github.event.workflow_run.head_repository.owner.login != github.event.workflow_run.repository.owner.login)
                && format('{0}:{1}', github.event.workflow_run.head_repository.owner.login, github.event.workflow_run.head_branch)
                || github.event.workflow_run.head_branch
            }}
        # Query the PR number by repo + branch, then assign to step output:
        run: gh pr view --repo "${PR_TARGET_REPO}" "${PR_BRANCH}" --json 'number' --jq '"number=\(.number)"' >> "${GITHUB_OUTPUT}"

      - name: 'PR comment - Bundle size'
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          number: ${{ steps.pr-context.outputs.number }}
          header: ${{ env.BUNDLE_SIZE_COMMENT_ID_PREFIX }}-${{ matrix.cli-version-alias }}
          path: bundle-size-pr-comment.md

I stripped out your original comments to try keep it minimal. The main difference is covered after your actions/download-artifact where I replaced the remaining steps with these two.

• gh pr view to query the PR number.
  • This requires a little bit of conditional logic to provide the correct branch ref for the repo to match.
  • The conditional needs |- instead of | for multi-line to avoid a trailing \n being part of the PR_BRANCH variable queried.
• marocchino/sticky-pull-request-comment is an alternative action that I've used for a few years now. It does both the find + comment actions functionality for PRs. The user matched is the github bot it posts as with header for the hidden identifier in the comment content. You can use path for a file input as you have, or other readers may prefer message to provide the comment body as a direct value.

The pr-context step will fail the job if it hits an error, so there is no conditional for the next step as it either found the PR number or didn't. In the action log, such a failure for the pr-context step looks like this:

no pull requests found for branch "some-owner:some-branch-name"
Error: Process completed with exit code 1.

---

PR_BRANCH conditional expression aside, it's much simpler for getting the PR number 👍

[davidlj95]

Great work @polarathene ! 💪 And thanks a lot for sharing it ❤️ You went deep down this rabbit hole 🐰 👀

Nice trick the one about gh pr view <branch>! At the expense of the conditional expression to find the PR branch. But it's a veeery reasonable trade-off.

I've been reading your options comment and the one with pull_request_target + reusable workflows looks better indeed. I'll keep an eye on the discussion in your PR with this approach to see if it's as safe and change to that at some point if it is. TBH I think I missed the comment in here introducing this approach. Otherwise would have chosen that way indeed.

Thanks also for sharing the marocchino/sticky-pull-request-comment action! Looks fits the needs with just one action, noice! 💪

PD: thanks also for the tip about erroring in finding the PR step to save some ifs

[polarathene]

I've been reading your options comment and the one with pull_request_target + reusable workflows looks better indeed.

For others reading this discussion thread, the linked PR discussion received feedback from the GHSL team about more risks involved that you'd need to be wary of introducing.

It's still viable, but really highlights how many footguns you (and any potential future maintainers) need to be mindful of avoiding, that I now heavily discourage this choice unless you're the sole maintainer, and confident that these caveats won't be forgotten months/years later when updating a workflow 😬 (easy mistake when a PR to the workflow with a minimal diff arrives, if you don't view the full workflow for any warning comments)

I've updated the reference comparison accordingly to caution Solution C (pull_request_target).

[frezbo]

I would be nice if this info is available natively from the workflow_run event rather than resorting to finding the PR number

[Pilzinsel64]

Yea, this is true! It avoids people from (theoretically) manipulate the workflow behavior by changing the artifacts.

[bric3]

Actually even from the REST API the pull request array is empty and it's not even a fork.

# curl -L
#  -H "Accept: application/vnd.github+json"
#  -H "Authorization: Bearer <YOUR-TOKEN>"
#  -H "X-GitHub-Api-Version: 2022-11-28"
#  https://api.github.com/repos/OWNER/REPO/actions/runs

GET https://api.github.com/repos/bric3/jufmt/actions/runs
Accept: application/vnd.github+json
Authorization: Bearer <token>
X-GitHub-Api-Version: 2022-11-28

A run that ran on a pull request

• https://github.com/bric3/jufmt/actions/runs/6223317359

In the payload below notice "event": "pull_request", and "pull_requests": [] is empty.

    {
      "id": 6223317359,
      "name": "Java CI with Gradle",
      "node_id": "WFR_kwLOEufiyM8AAAABcvBJbw",
      "head_branch": "windows-failure",
      "head_sha": "0a1e93ee775f4311bf61aa78171890c1937c7c6d",
      "path": ".github/workflows/gradle.yml",
      "display_title": "Understand windows failure",
      "run_number": 242,
      "event": "pull_request",
      "status": "completed",
      "conclusion": "success",
      "workflow_id": 20103782,
      "check_suite_id": 16285471685,
      "check_suite_node_id": "CS_kwDOEufiyM8AAAADyrCTxQ",
      "url": "https://api.github.com/repos/bric3/jufmt/actions/runs/6223317359",
      "html_url": "https://github.com/bric3/jufmt/actions/runs/6223317359",
      "pull_requests": [],
      "created_at": "2023-09-18T13:35:21Z",
      "updated_at": "2023-09-18T13:42:56Z",
      "actor": {
        "login": "bric3",
        "id": 803621,
        "node_id": "MDQ6VXNlcjgwMzYyMQ==",
        "avatar_url": "https://avatars.githubusercontent.com/u/803621?v=4",
        "gravatar_id": "",
        "url": "https://api.github.com/users/bric3",
        "html_url": "https://github.com/bric3",
        "followers_url": "https://api.github.com/users/bric3/followers",
        "following_url": "https://api.github.com/users/bric3/following{/other_user}",
        "gists_url": "https://api.github.com/users/bric3/gists{/gist_id}",
        "starred_url": "https://api.github.com/users/bric3/starred{/owner}{/repo}",
        "subscriptions_url": "https://api.github.com/users/bric3/subscriptions",
        "organizations_url": "https://api.github.com/users/bric3/orgs",
        "repos_url": "https://api.github.com/users/bric3/repos",
        "events_url": "https://api.github.com/users/bric3/events{/privacy}",
        "received_events_url": "https://api.github.com/users/bric3/received_events",
        "type": "User",
        "site_admin": false
      },
      "run_attempt": 1,
      "referenced_workflows": [],
      "run_started_at": "2023-09-18T13:35:21Z",
      "triggering_actor": {
        "login": "bric3",
        "id": 803621,
        "node_id": "MDQ6VXNlcjgwMzYyMQ==",
        "avatar_url": "https://avatars.githubusercontent.com/u/803621?v=4",
        "gravatar_id": "",
        "url": "https://api.github.com/users/bric3",
        "html_url": "https://github.com/bric3",
        "followers_url": "https://api.github.com/users/bric3/followers",
        "following_url": "https://api.github.com/users/bric3/following{/other_user}",
        "gists_url": "https://api.github.com/users/bric3/gists{/gist_id}",
        "starred_url": "https://api.github.com/users/bric3/starred{/owner}{/repo}",
        "subscriptions_url": "https://api.github.com/users/bric3/subscriptions",
        "organizations_url": "https://api.github.com/users/bric3/orgs",
        "repos_url": "https://api.github.com/users/bric3/repos",
        "events_url": "https://api.github.com/users/bric3/events{/privacy}",
        "received_events_url": "https://api.github.com/users/bric3/received_events",
        "type": "User",
        "site_admin": false
      },
      "jobs_url": "https://api.github.com/repos/bric3/jufmt/actions/runs/6223317359/jobs",
      "logs_url": "https://api.github.com/repos/bric3/jufmt/actions/runs/6223317359/logs",
      "check_suite_url": "https://api.github.com/repos/bric3/jufmt/check-suites/16285471685",
      "artifacts_url": "https://api.github.com/repos/bric3/jufmt/actions/runs/6223317359/artifacts",
      "cancel_url": "https://api.github.com/repos/bric3/jufmt/actions/runs/6223317359/cancel",
      "rerun_url": "https://api.github.com/repos/bric3/jufmt/actions/runs/6223317359/rerun",
      "previous_attempt_url": null,
      "workflow_url": "https://api.github.com/repos/bric3/jufmt/actions/workflows/20103782",
      "head_commit": {
        "id": "0a1e93ee775f4311bf61aa78171890c1937c7c6d",
        "tree_id": "e2e909cfe4c4b248531a510b444557f68f3ce506",
        "message": "chore: Moves figlet test in lib, and use mockito in cli",
        "timestamp": "2023-09-18T13:34:58Z",
        "author": {
          "name": "Brice Dutheil",
          "email": "[email protected]"
        },
        "committer": {
          "name": "Brice Dutheil",
          "email": "[email protected]"
        }
      },
      "repository": {
        "id": 317186760,
        "node_id": "MDEwOlJlcG9zaXRvcnkzMTcxODY3NjA=",
        "name": "jufmt",
        "full_name": "bric3/jufmt",
        "private": false,
        "owner": {
          "login": "bric3",
          "id": 803621,
          "node_id": "MDQ6VXNlcjgwMzYyMQ==",
          "avatar_url": "https://avatars.githubusercontent.com/u/803621?v=4",
          "gravatar_id": "",
          "url": "https://api.github.com/users/bric3",
          "html_url": "https://github.com/bric3",
          "followers_url": "https://api.github.com/users/bric3/followers",
          "following_url": "https://api.github.com/users/bric3/following{/other_user}",
          "gists_url": "https://api.github.com/users/bric3/gists{/gist_id}",
          "starred_url": "https://api.github.com/users/bric3/starred{/owner}{/repo}",
          "subscriptions_url": "https://api.github.com/users/bric3/subscriptions",
          "organizations_url": "https://api.github.com/users/bric3/orgs",
          "repos_url": "https://api.github.com/users/bric3/repos",
          "events_url": "https://api.github.com/users/bric3/events{/privacy}",
          "received_events_url": "https://api.github.com/users/bric3/received_events",
          "type": "User",
          "site_admin": false
        },
        "html_url": "https://github.com/bric3/jufmt",
        "description": "Java Unicode formatter",
        "fork": false,
        "url": "https://api.github.com/repos/bric3/jufmt",
        "forks_url": "https://api.github.com/repos/bric3/jufmt/forks",
        "keys_url": "https://api.github.com/repos/bric3/jufmt/keys{/key_id}",
        "collaborators_url": "https://api.github.com/repos/bric3/jufmt/collaborators{/collaborator}",
        "teams_url": "https://api.github.com/repos/bric3/jufmt/teams",
        "hooks_url": "https://api.github.com/repos/bric3/jufmt/hooks",
        "issue_events_url": "https://api.github.com/repos/bric3/jufmt/issues/events{/number}",
        "events_url": "https://api.github.com/repos/bric3/jufmt/events",
        "assignees_url": "https://api.github.com/repos/bric3/jufmt/assignees{/user}",
        "branches_url": "https://api.github.com/repos/bric3/jufmt/branches{/branch}",
        "tags_url": "https://api.github.com/repos/bric3/jufmt/tags",
        "blobs_url": "https://api.github.com/repos/bric3/jufmt/git/blobs{/sha}",
        "git_tags_url": "https://api.github.com/repos/bric3/jufmt/git/tags{/sha}",
        "git_refs_url": "https://api.github.com/repos/bric3/jufmt/git/refs{/sha}",
        "trees_url": "https://api.github.com/repos/bric3/jufmt/git/trees{/sha}",
        "statuses_url": "https://api.github.com/repos/bric3/jufmt/statuses/{sha}",
        "languages_url": "https://api.github.com/repos/bric3/jufmt/languages",
        "stargazers_url": "https://api.github.com/repos/bric3/jufmt/stargazers",
        "contributors_url": "https://api.github.com/repos/bric3/jufmt/contributors",
        "subscribers_url": "https://api.github.com/repos/bric3/jufmt/subscribers",
        "subscription_url": "https://api.github.com/repos/bric3/jufmt/subscription",
        "commits_url": "https://api.github.com/repos/bric3/jufmt/commits{/sha}",
        "git_commits_url": "https://api.github.com/repos/bric3/jufmt/git/commits{/sha}",
        "comments_url": "https://api.github.com/repos/bric3/jufmt/comments{/number}",
        "issue_comment_url": "https://api.github.com/repos/bric3/jufmt/issues/comments{/number}",
        "contents_url": "https://api.github.com/repos/bric3/jufmt/contents/{+path}",
        "compare_url": "https://api.github.com/repos/bric3/jufmt/compare/{base}...{head}",
        "merges_url": "https://api.github.com/repos/bric3/jufmt/merges",
        "archive_url": "https://api.github.com/repos/bric3/jufmt/{archive_format}{/ref}",
        "downloads_url": "https://api.github.com/repos/bric3/jufmt/downloads",
        "issues_url": "https://api.github.com/repos/bric3/jufmt/issues{/number}",
        "pulls_url": "https://api.github.com/repos/bric3/jufmt/pulls{/number}",
        "milestones_url": "https://api.github.com/repos/bric3/jufmt/milestones{/number}",
        "notifications_url": "https://api.github.com/repos/bric3/jufmt/notifications{?since,all,participating}",
        "labels_url": "https://api.github.com/repos/bric3/jufmt/labels{/name}",
        "releases_url": "https://api.github.com/repos/bric3/jufmt/releases{/id}",
        "deployments_url": "https://api.github.com/repos/bric3/jufmt/deployments"
      },
      "head_repository": {
        "id": 317186760,
        "node_id": "MDEwOlJlcG9zaXRvcnkzMTcxODY3NjA=",
        "name": "jufmt",
        "full_name": "bric3/jufmt",
        "private": false,
        "owner": {
          "login": "bric3",
          "id": 803621,
          "node_id": "MDQ6VXNlcjgwMzYyMQ==",
          "avatar_url": "https://avatars.githubusercontent.com/u/803621?v=4",
          "gravatar_id": "",
          "url": "https://api.github.com/users/bric3",
          "html_url": "https://github.com/bric3",
          "followers_url": "https://api.github.com/users/bric3/followers",
          "following_url": "https://api.github.com/users/bric3/following{/other_user}",
          "gists_url": "https://api.github.com/users/bric3/gists{/gist_id}",
          "starred_url": "https://api.github.com/users/bric3/starred{/owner}{/repo}",
          "subscriptions_url": "https://api.github.com/users/bric3/subscriptions",
          "organizations_url": "https://api.github.com/users/bric3/orgs",
          "repos_url": "https://api.github.com/users/bric3/repos",
          "events_url": "https://api.github.com/users/bric3/events{/privacy}",
          "received_events_url": "https://api.github.com/users/bric3/received_events",
          "type": "User",
          "site_admin": false
        },
        "html_url": "https://github.com/bric3/jufmt",
        "description": "Java Unicode formatter",
        "fork": false,
        "url": "https://api.github.com/repos/bric3/jufmt",
        "forks_url": "https://api.github.com/repos/bric3/jufmt/forks",
        "keys_url": "https://api.github.com/repos/bric3/jufmt/keys{/key_id}",
        "collaborators_url": "https://api.github.com/repos/bric3/jufmt/collaborators{/collaborator}",
        "teams_url": "https://api.github.com/repos/bric3/jufmt/teams",
        "hooks_url": "https://api.github.com/repos/bric3/jufmt/hooks",
        "issue_events_url": "https://api.github.com/repos/bric3/jufmt/issues/events{/number}",
        "events_url": "https://api.github.com/repos/bric3/jufmt/events",
        "assignees_url": "https://api.github.com/repos/bric3/jufmt/assignees{/user}",
        "branches_url": "https://api.github.com/repos/bric3/jufmt/branches{/branch}",
        "tags_url": "https://api.github.com/repos/bric3/jufmt/tags",
        "blobs_url": "https://api.github.com/repos/bric3/jufmt/git/blobs{/sha}",
        "git_tags_url": "https://api.github.com/repos/bric3/jufmt/git/tags{/sha}",
        "git_refs_url": "https://api.github.com/repos/bric3/jufmt/git/refs{/sha}",
        "trees_url": "https://api.github.com/repos/bric3/jufmt/git/trees{/sha}",
        "statuses_url": "https://api.github.com/repos/bric3/jufmt/statuses/{sha}",
        "languages_url": "https://api.github.com/repos/bric3/jufmt/languages",
        "stargazers_url": "https://api.github.com/repos/bric3/jufmt/stargazers",
        "contributors_url": "https://api.github.com/repos/bric3/jufmt/contributors",
        "subscribers_url": "https://api.github.com/repos/bric3/jufmt/subscribers",
        "subscription_url": "https://api.github.com/repos/bric3/jufmt/subscription",
        "commits_url": "https://api.github.com/repos/bric3/jufmt/commits{/sha}",
        "git_commits_url": "https://api.github.com/repos/bric3/jufmt/git/commits{/sha}",
        "comments_url": "https://api.github.com/repos/bric3/jufmt/comments{/number}",
        "issue_comment_url": "https://api.github.com/repos/bric3/jufmt/issues/comments{/number}",
        "contents_url": "https://api.github.com/repos/bric3/jufmt/contents/{+path}",
        "compare_url": "https://api.github.com/repos/bric3/jufmt/compare/{base}...{head}",
        "merges_url": "https://api.github.com/repos/bric3/jufmt/merges",
        "archive_url": "https://api.github.com/repos/bric3/jufmt/{archive_format}{/ref}",
        "downloads_url": "https://api.github.com/repos/bric3/jufmt/downloads",
        "issues_url": "https://api.github.com/repos/bric3/jufmt/issues{/number}",
        "pulls_url": "https://api.github.com/repos/bric3/jufmt/pulls{/number}",
        "milestones_url": "https://api.github.com/repos/bric3/jufmt/milestones{/number}",
        "notifications_url": "https://api.github.com/repos/bric3/jufmt/notifications{?since,all,participating}",
        "labels_url": "https://api.github.com/repos/bric3/jufmt/labels{/name}",
        "releases_url": "https://api.github.com/repos/bric3/jufmt/releases{/id}",
        "deployments_url": "https://api.github.com/repos/bric3/jufmt/deployments"
      }
    },

[alltilla]

This is still a problem.

Interestingly, the gh run view command shows us the PR number in its formatted output. No json field for it though...
I made a "oneliner" workaround which gets the PR ID from the gh run view output, but it relies on the formatting and might break in the future:

      - name: Get PR ID
        id: pr-id
        run: |
          PR_ID=$(gh run view -R ${{ github.repository }} ${{ github.event.workflow_run.id }} | grep -oP '#[0-9]+ . ${{ github.event.workflow_run.id }}' | grep -oP '#[0-9]+' | cut -c 2-)
          echo "pr-id=${PR_ID}" >> $GITHUB_OUTPUT

You can access the PR ID in the following steps with ${{ steps.pr-id.outputs.pr-id }}.

The things you have to do to simply comment on a PR originated from a fork is unreal.

[alltilla]

@OverOrion suggested to query a PR with the fork owner's login and the head branch, which are available in the workflow_run context.

      - name: Get PR ID
        id: pr-id
        run: |
          PR_ID=$(gh pr view -R "${{ github.repository }}" "${{ github.event.workflow_run.head_repository.owner.login }}:${{ github.event.workflow_run.head_branch }}" --json "number" --jq ".number")
          echo "pr-id=${PR_ID}" >> $GITHUB_OUTPUT

This does not depend on a formatted output.

[nomeata]

Nice! You can actually use jq to directly produce output that can go to $GITHUB_OUTPUT, something like

        run: |
          gh pr view -R "${{ github.repository }}" "${{ github.event.workflow_run.head_repository.owner.login }}:${{ github.event.workflow_run.head_branch }}" \
            --json number,headRefOid --jq '"pullRequestNumber=\(.number)\nsourceHeadSha=\(.headRefOid)"' > $GITHUB_OUTPUT

[nomeata]

Hmm, didn’t work for me,

no pull requests found for branch "nomeata:joachim/test-simpler-pr-release"

when it’s a PR that is not from a fork.

In any case, don’t we have to worry that ${{ github.event.workflow_run.head_branch }} contains bad characters?

[polarathene]

UPDATE: Some reference workflow examples for gh pr view:

• https://github.com/orgs/community/discussions/25220#discussioncomment-11300118
• ci(docs-preview): Acquire PR context via gh CLI docker-mailserver/docker-mailserver#4267 (comment)

Best practice - Avoid using expressions syntax directly in scripts

In any case, don’t we have to worry that ${{ github.event.workflow_run.head_branch }} contains bad characters?

Yes, GHSL advises you to set the context expression in env for the step instead, and have the script reference the ENV variable at run time instead of allowing the content to inject into the content of the script itself before it's processed (which is often how known exploits have been leveraged, that would otherwise have been prevented).

---

gh pr view branch compatibility

no pull requests found for branch "nomeata:joachim/test-simpler-pr-release"

when it’s a PR that is not from a fork.

If you check the PR page on your repo, you'll notice a difference. PRs from forks will have the fork owner prefixed with : as a delimiter, while PRs on the same repo do not have that.

Here's an example from a repo where I have made two PRs (one from my fork and one directly on the original repo):

$ gh pr view --json number --jq .number --repo docker-mailserver/docker-mailserver polarathene:fix/saslauthd-drop-invalid-mysql-config
4259

$ gh pr view --json number --jq .number --repo docker-mailserver/docker-mailserver docs/smtp-bind-fix-snippet-titles
4258

Example workflow that conditionally handles the branch name:

# Minimum read permissions needed for `gh pr view`:
permissions:
  pull-requests: read
  contents: read

jobs:
# ...
  steps:
      - name: 'Get PR context'
        id: pr-context
        env:
          # Token required for GH CLI:
          GH_TOKEN: ${{ github.token }}
          # Best practice for scripts is to reference via ENV at runtime. Avoid using the expression syntax in the script content directly:
          PR_TARGET_REPO: ${{ github.repository }}
          # If the PR is from a fork, prefix it with `<owner-login>:`, otherwise only the PR branch name is relevant:
          PR_BRANCH: |-
            ${{
              (github.event.workflow_run.head_repository.owner.login != github.event.workflow_run.repository.owner.login)
                && format('{0}:{1}', github.event.workflow_run.head_repository.owner.login, github.event.workflow_run.head_branch)
                || github.event.workflow_run.head_branch
            }}
        # Use GH CLI to query the PR branch for the PR number and assign it to the steps output:
        # (`--jq` formats JSON to `key=value` pairs and renames `headRefOid` to `head-sha`)
        run: |
          gh pr view --repo "${PR_TARGET_REPO}" "${PR_BRANCH}" \
            --json 'number,headRefOid' \
            --jq '"number=\(.number)\nhead-sha=\(.headRefOid)"' \
            >> $GITHUB_OUTPUT

You can now use ${{ steps.pr-context.outputs.number }} and ${{ steps.pr-context.outputs.head-sha }} at a later step 👍

---

Rate limits

This approach may be affected by rate-limits depending on your project + workflows activity.

• REST API rate limit docs for GITHUB_TOKEN usage (1,000 requests per hour)
• REST API rate limit query docs (gh CLI can call this to check the limit in your workflow)

I observed my workflow was increasing the limit of core by 7 each time, but this gh pr view had no impact on that. gh pr view did seem to increment the graphql limit by 1 though. The limits were not at 1000 though, they were reported to have a 5000 request limit which is for an authenticated user (I was re-running the workflow or triggering one via new commits to a PR).

Thus it seems the gh pr view approach isn't likely to contribute to a rate limit issue, especially if something else in the workflow would exceed the core limit before graphql.

There are also the secondary rate limits that are more likely to be hit, but for smaller/simpler projects should be fine 👍 (EDIT: One of the REST API examples from another user hit the secondary rate limit, but this should minimize that risk AFAIK?)

[davidlj95]

I just came across the issue and found out (yet) another workaround. I prefer to avoid using artifacts to send the PR number information as those could be altered.

It's inspired on @danepowell 's workaround in the GH Action Get Workflow Origin. It lists latest PRs in repository and looks for the one whose head commit SHA matches the workflow run head SHA (which we have in the event payload). It's a bit hacky, given we can't specify in the API call that we want the PR whose head SHA is that one and we have to look in the list of latest PRs in the repository. Also, the action is not maintained anymore 😢 So you'd have to copy that piece into a GitHub script step.

Then I found out that using GitHub's issues & PRs search API we can look for the PR given the head SHA

Here's the magic script: 🪄

- name: Find associated pull request
  id: pr
  uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea # v7
  with:
    script: |
      const response = await github.rest.search.issuesAndPullRequests({
        q: 'repo:${{ github.repository }} is:pr sha:${{ github.event.workflow_run.head_sha }}',
        per_page: 1,
      })
      const items = response.data.items
      if (items.length < 1) {
        console.error('No PRs found')
        return
      }
      const pullRequestNumber = items[0].number
      console.info("Pull request number is", pullRequestNumber)
      return pullRequestNumber

https://github.com/davidlj95/ngx/blob/d9b6aa1b2f574d53af083b18166cba2ff9b1f26c/.github/workflows/pull-request-completed.yml#L44-L60

And here's how the PR number is used

- name: Find bundle size PR comment
  uses: peter-evans/find-comment@d5fe37641ad8451bdd80312415672ba26c86575e # v3
  id: fc
  with:
    issue-number: ${{ steps.pr.outputs.result }} # 👈
    comment-author: 'github-actions[bot]'
    body-includes: ${{ env.BUNDLE_SIZE_COMMENT_ID_PREFIX }}${{ matrix.version }}

https://github.com/davidlj95/ngx/blob/d9b6aa1b2f574d53af083b18166cba2ff9b1f26c/.github/workflows/pull-request-completed.yml#L65

[davidlj95]

Update: from time to time, you may get rate limit errors given search API seems to use many calls internally.

Specific error:

RequestError [HttpError]: You have exceeded a secondary rate limit. Please wait a few minutes before you try again. If you reach out to GitHub Support for help, please include the request ID 5080:999B:13E49C5:24FD47C:65FB0DC2.
    at /home/runner/work/_actions/actions/github-script/60a0d83039c74a4aee543508d2ffcb1c3799cdea/dist/index.js:9537:21
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async eval (eval at callAsyncFunction (/home/runner/work/_actions/actions/github-script/60a0d83039c74a4aee543508d2ffcb1c3799cdea/dist/index.js:35424:16), <anonymous>:3:18)
    at async main (/home/runner/work/_actions/actions/github-script/60a0d83039c74a4aee543508d2ffcb1c3799cdea/dist/index.js:35522:20) {
  status: 403,

Even with retries added (set to 3 in github-script)

[ImLucasBrown]

This saved me so much pain thank you! Two tiny modification I found I needed, to get a reusable workflow working, was to filter for merged PRs and to use the sha from the github object.

q: 'repo:${{ github.repository }} is:pr is:merged sha:${{ github.sha }}'

[Kas-tle]

The more you look at it the more it seems they really really really do not want you to know from the API what PR number is associated with a workflow run... but they're happy to show you in the UI and in an unformatted part of CLI output as someone else pointed out... baffling. Even if you query the workflow run from the API there's absolutely no indication of what triggered it.

I don't really love the checking by owner and branch name solutions as that could technically be changed while the action is running. So hopefully GitHub provides an actual fix at some point.

[Kas-tle]

Can you please show where you're getting this from in the docs? The page you linked only makes this statement about self hosted runners. If you run a workflow with multiple jobs that nest workflows and just take a look at the logs, it's pretty clear all the nested workflows run on separate runners.

Furthermore, secrets must be passed explicitly to nested workflows. See https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-secrets-to-nested-workflows. Why would this be the case if, as you seem to be positing, all the nested workflows can actually just access them anyways?

[neongreen]

Ok, looks like you're right re/ job isolation — https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners says each job runs in its own VM, which makes sense.

I filed an issue in github/docs to clarify the doc, since I can't figure out where it says the statement only applies to self-hosted runners.

Why would this be the case if, as you seem to be positing, all the nested workflows can actually just access them anyways?

That's exactly what I posited, so I'm glad to be wrong

[polarathene]

FWIW, I chose to go with the approach discussed here vs others. It's awaiting review from someone on the GHSL (Github Security Labs) team, so if they chime in with their approval, that should alleviate any concerns :)

You can view it here, as a real-world example to reference. It's focused on generating preview docs for PRs and adding a comment to the PR with the preview link after deployment. Fairly common use-case, and I've documented it fairly well that even with little experience with Github Actions, it should be simple enough to grok 😎

[neongreen]

Awesome, please follow up if GHSL responds!

[polarathene]

please follow up if GHSL responds!

Review feedback from GHSL has been quite insightful and as a result given the type of project and reasonable size of popularity, I've chosen not to risk it.

Per that feedback linked, GHSL has endorsed solutions A and B (both implement workflows with pull_request + workflow_run):

• Solution A (value transfer via file artifacts loaded into $GITHUB_ENV / $GITHUB_OUTPUT with a validation step)
• Solution B (gh pr view) - This is the preferred choice for PR metadata (number, sha, etc)

Solution C (pull_request_target + workflow_call) may be viable for you if the impact of compromise is acceptable, which should be low in a very well locked down environment.

---

The cache poisoning technique to hijack other workflows within the same branch boundary paired with secret extraction via memory dump is quite concerning, especially if you do not have a manual trigger mechanism to approve the workflow when PRs are from forks, this is how Google had their Angular repo compromised via pull_request_target.

pull_request avoids that thanks to the branch boundary with cache, and can more easily be restricted to manual approval should you want the extra precaution.

[maryada-lodha-5006976]

jobs:
get-pr:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3

  - name: Extract Pull Request Number
    id: extract_pr_number
    run: |
      pr_number=$(echo ${{ github.event.workflow_run.pull_requests[0].number }})
      echo "PR_NUMBER=${pr_number}" >> $GITHUB_ENV

  - name: Output PR Number
    run: echo ${{ env.PR_NUMBER }}

[polarathene]

You have not read the discussion here.

The problem is github.event.workflow_run.pull_requests is empty when the PR is not from your repo but from a fork (which anyone unable to create a branch on your repo, like most contributors cannot, must fork the repo to create a PR).

[polarathene]

I've commented on most of the answers posted here while investigating what the most appropriate approach is in 2024. In doing so I've also reached out to GitHub Security Labs (GHSL) staff and received feedback on these different solutions.

---

TL;DR: Go with Solution B (gh pr view) 😎

I have documented a detailed reference for comparing these solutions with additional insights/differences covered there. B and C also have full workflow examples.

Solutions A and B are workflows using pull_request + workflow_run triggers. Most of you will be served well by Solution B, otherwise Solution A for any other data that you need to pass over from pull_request.

Solutions

• ✅ Solution A (pass inputs via artifacts, validate and load into $GITHUB_ENV or $GITHUB_OUTPUT)
  • GHSL previously blogged about this approach in Aug 2021, where variations have been adopted, some insecurely (I was guilty of this myself).
  • The modern variant of this approach in 2024 uses actions/upload-artifact + actions/download-artifact instead of scripts to manage the artifact transfer.
  • Do not blindly transfer as an .env file to append to $GITHUB_ENV in your secure workflow stage. pull_request triggered workflows may be modified by the PR author to do as they choose. First-time contributors require manual approval for a pull_request workflow to be run, but unless you've enforced the approval requirement this won't be much of a deterrent to the attacker (unless I'm mistaken and modifications to pull_request workflows from non-collaborators are an exception that enforce manual approval to run? 🤷‍♂️ ).
  • Validate and assign inputs explicitly. You do not want to allow the PR author to exploit workflow_run via LD_PRELOAD. The PR author could still alter these values to valid ones that target different pull requests instead for example; if that's a concern prefer Solution B.
• ✅ 🚀 Solution B (gh pr view) - Preferred
  • This is considered the safest approach of the three by GHSL.
  • Slightly awkward with the branch selection (PR branch from repo vs fork), but otherwise very simple and straight-forward to get PR metadata securely. Unlike the github.event.workflow_run.pull_requests context being empty/incompatible with PRs from forks.
• ⚠️ Solution C (pull_request_target + workflow_call) - Dangerous
  • You should already know choosing pull_request_target requires caution due to the risks it poses, however if the attacker can influence the workflow to run untrusted code, there can be various non-obvious routes of attack beyond human error and social engineering. You must be confident your workflow is secure, and that any compromise from unknowns is acceptable to your project / users.
  • I was made aware of several CI environment specific attack vectors that can be exploited by the attack executing a payload on the runner. As this is an area subject to silently change over time, it's also not something you'll likely stay on top of.
  • pull_request_target is considered to run in a trusted context, thus your pull_request approval policy has no affect here. Once you bring in untrusted code from an external source like a PR to run, you are at risk (which led to a compromise for Angular due to running modified script from a PR via a workflow triggered from the default branch)

Example - Solution B

Besides the full real-world example in the earlier comparisons reference link, here are two more references that I shared in this discussion:

• https://github.com/orgs/community/discussions/25220#discussioncomment-11285971
• https://github.com/orgs/community/discussions/25220#discussioncomment-11300118

Here's a rough snippet for it's use in a workflow triggered by workflow_run. It gets the PR number and assigns it to an output (you could choose ${GITHUB_ENV} instead if you prefer that):

name: 'Documentation (Deploy)'

on:
  workflow_run:
    workflows: ['Documentation (PR)']
    types:
      - completed

permissions:
  # Required by `pr-context` step:
  contents: read
  # Required by `marocchino/sticky-pull-request-comment` (write) + `pr-context` step (read):
  pull-requests: write

jobs:
# ...
  steps:
      - name: 'Get PR context'
        id: pr-context
        env:
          # Token required for GH CLI:
          GH_TOKEN: ${{ github.token }}
          # Best practice for scripts is to reference via ENV at runtime. Avoid using the expression syntax in the script content directly:
          PR_TARGET_REPO: ${{ github.repository }}
          # If the PR is from a fork, prefix it with `<owner-login>:`, otherwise only the PR branch name is relevant:
          PR_BRANCH: |-
            ${{
              (github.event.workflow_run.head_repository.owner.login != github.event.workflow_run.repository.owner.login)
                && format('{0}:{1}', github.event.workflow_run.head_repository.owner.login, github.event.workflow_run.head_branch)
                || github.event.workflow_run.head_branch
            }}
        # Query the PR number by repo + branch, then assign to step output:
        run: |
          gh pr view --repo "${PR_TARGET_REPO}" "${PR_BRANCH}" \
             --json 'number' --jq '"number=\(.number)"' \
             >> "${GITHUB_OUTPUT}"

     # ...

      - name: 'Comment on PR with preview link'
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          number: ${{ steps.pr-context.outputs.number }}
          header: preview-comment
          recreate: true
          message: |
            [Documentation preview for this PR](${{ steps.preview-netlify.outputs.deploy-url }}) is ready! :tada:

If the gh pr view command fails to find the PR, it'll error and the step will be failed, which unless you've configured any steps to always run, that job will stop 👍

[Kas-tle]

I almost thought I had a breakthrough, but alas of course GitHub's API inconsistencies ruin it. You can make a request like so to the Github API to show PRs associated with a given commit:

https://api.github.com/repos/{owner}/{repo}/commits/{commit}/pulls

For this, we need to use the owner of the repo that is attempting to merge the PR, not our own. The sha/owner are easy enough: github.event.workflow_run.head_sha and github.event.workflow_run.head_repository.owner.login.

It would be especially nice if this worked since it still seems to find the pull request even if there's been another commit since. The problem, however, is that this does not seem to work consistently. I am still trying to work out why this seems to be happening. It seems to happen on a per-user basis, so I think it may somehow be related to user activity settings somehow? (though I do see the PR on their wall still in these cases). I have also personally only observed it on people contributing to the organization for the first time.

But then I stumbled on something kinda interesting. It turns out that GitHub actually adds a ref for each pull request under refs/pull/{number}/head. So with something along the lines of:

git ls-remote $main_repo_url 'pull/*/head' | grep $commit | cut -d'/' -f3

You then have the number with 0 API calls and obtained from your own repo. The caveat here though is that this will fail if there have been more commits on the PR. In some contexts though that might be desirable. You may also want to add some logic for the unlikely, but technically possible, case that you end up with people opening PRs for the same changes for some reason.

[Kas-tle]

Are they aware/acknowledging an issue with it? Otherwise I don't know if much will change 🤔

In my support request they acknowledged that multiple people had reported the same issue and then asked me to check again to see if it had been resolved. It had been for one of the examples I gave them, but not the other. I told them this and they said they would continue investigating and let me know when it is fully resolved. So yes they at least seem to acknowledge that it should work and they want to fix it.

[Kas-tle]

No, absolutely not. There is advice here that has the pull_request workflow upload ENV as an artifact, and then in the workflow_run 2nd workflow download the artifact and load it into ENV (EDIT: This is not suggested in this discussion, but it has been elsewhere where it's a security vulnerability).

So as I said, in this discussion thread...?

[polarathene]

So as I said, in this discussion thread...?

Yeah, hence the edit. The original text was kept in the event someone posts an answer in this discussion that does suggest something insecure 🤷‍♂️

---

So yes they at least seem to acknowledge that it should work and they want to fix it.

Awesome, thanks for clarifying that! 😁

---

In the meantime, this search query appears to be the most reliable choice?:

# Query locates this PR: https://github.com/docker-mailserver/docker-mailserver/pull/1661
# Technically `PR_BRANCH` is not necessary here due to `PR_SHA`:
$ export PR_TARGET_REPO='docker-mailserver/docker-mailserver' PR_BRANCH='patch-1' PR_SHA='047ffd6'
$ export SEARCH_QUERY="type:pr state:open sort:updated-desc repo:${PR_TARGET_REPO} head:${PR_BRANCH} ${PR_SHA}"


# GraphQL API:
$ gh api graphql \
  --field "filter=${SEARCH_QUERY}" \
  --raw-field query='query($filter: String!) { search( query: $filter, type: ISSUE, first: 1) {
    nodes { ... on PullRequest { number } }
  }}' \
  --jq '.data.search.nodes[0].number'

1661


# REST API:
$ gh api search/issues --method GET --field "q=${SEARCH_QUERY}" --jq '.items.[0].number'

1661

In testing, I found that the REST API search/issues endpoint was quite easy to hit rate limits:

gh: You have exceeded a secondary rate limit

• It was not exactly clear which one. I had only done about 10 requests to the endpoint within an hour and received
• I have not encountered that failure with the GraphQL search query equivalent, even when queried more frequently.

---

Full workflow example (for graphql search)

Adapted from the CLI example above:

• SEARCH_QUERY and GQL are a bit verbose for just a PR number :(
• JQ_FILTER is mostly verbose for the error handling + formatting. If you don't need to format the value for GITHUB_ENV/GITHUB_OUTPUT, you could keep it simple like the CLI example above.
  • --jq '.data.search.nodes[0].number' - In the event this doesn't exist gh api returns nothing but exit status is 0.
  • --jq '.data.search.nodes[0]' | jq -e '.number' (or not having gh api use --jq at all) with the JSON result piped and processed via actual jq with -e, the step will actually fail for an output value of null / false.

name: 'Docs Preview (run)'
on:
  workflow_run:
    workflows: ['Docs Preview (PR)']
    types:
      - completed

jobs:
  example:
    name: 'Search Example'
    runs-on: ubuntu-24.04
    steps:
      - name: 'Get PR context'
        id: pr-context
        env:
          GH_TOKEN: ${{ github.token }}
          # Find the most recently updated open PR at the repo with the requested commit:
          SEARCH_QUERY: >-
            type:pr state:open sort:updated-desc
            repo:${{ github.repository }}
            ${{ github.event.workflow_run.head_sha }}
          # Minimal graphql search query to fetch the PR `number` field:
          GQL: |-
            query($filter: String!) {
              search( query: $filter, type: ISSUE, first: 1) {
                nodes { ... on PullRequest { number } }
              }
            }
          # Formats the GQL response into a `key=value` string + basic error handling
          JQ_FILTER: >-
            .data.search.nodes[0]
            | if (.number == null) then error("Could not find PR number") end
            | "pr_number=\(.number)"
        run: |
          gh api graphql --field "filter=${SEARCH_QUERY}" --raw-field "query=${GQL}" --jq "${JQ_GQL}" >> "${GITHUB_OUTPUT}"

      # Do something with the output/env in another step if you like:
      - name: 'Verify PR number is valid'
        env:
          PR_NUMBER: ${{ steps.pr-context.outputs.number }}
        run: |
          echo "PR Number: ${PR_NUMBER}"

An earlier workflow example (with a few extras fields/outputs and variations)

name: 'Docs Preview (run)'
on:
  workflow_run:
    workflows: ['Docs Preview (PR)']
    types:
      - completed

jobs:
  example:
    name: 'Search Example'
    runs-on: ubuntu-24.04
    # Only needed when `repo` is private:
    permissions:
      pull-requests: read
    steps:
      - name: 'Get PR context'
        id: pr-context
        shell: bash
        env:
          # Token required for GH CLI:
          GH_TOKEN: ${{ github.token }}
          SEARCH_QUERY: >-
            type:pr
            state:open
            sort:updated-desc
            repo:${{ github.repository }}
            head:${{ github.event.workflow_run.head_branch }}
            ${{ github.event.workflow_run.head_sha }}
          GQL: |-
            query($filter: String!) {
              search( query: $filter, type: ISSUE, first: 1) {
                nodes { ... on PullRequest { number, headRefName, headRefOid } }
              }
              # Uncomment for troubleshooting if you need to also query limits/cost:
              #rateLimit { cost, limit, remaining, used, resetAt }
            }
        run: |
          # Alternative REST example that only acquires the PR number:
          #JQ_REST='.items[0].number'
          #R_REST=$(gh api search/issues --method GET --field "q=${SEARCH_QUERY}" --jq "${JQ_REST}")

          # Get the desired fields as JSON:
          JQ_GQL='.data.search.nodes[0] | { number, head_branch: .headRefName, head_sha: .headRefOid }'
          R_GQL=$(gh api graphql --field "filter=${SEARCH_QUERY}" --raw-field "query=${GQL}" --jq "${JQ_GQL}")

          # Assign as an output or env var, with some basic error checking:
          echo "${R_GQL}" \
            | printf 'pr=%s\n' $(jq --compact-output) \
            | grep --invert-match '":null' \
            >> "${GITHUB_OUTPUT}"

      # Do something with the outputs/env in another step if you like:
      - name: 'Verify outputs'
        env:
          PR_NUMBER: ${{ fromJSON(steps.pr-context.outputs.pr).number }}
          PR_BRANCH: ${{ fromJSON(steps.pr-context.outputs.pr).head_branch }}
          PR_HEADSHA: ${{ fromJSON(steps.pr-context.outputs.pr).head_sha }}
        run: |
          echo "PR Number: ${PR_NUMBER} | PR Branch: ${PR_BRANCH} | PR SHA (latest commit): ${PR_HEADSHA}"

Error handling advice/notes (click to expand)

These notes go over details for failing a step early and better error handling practices to keep in mind.

Without additional context for the failure, if a command returns a non-zero exit code the step exits early with the workflow log showing:

Error: Process completed with exit code 1.

shell: bash for equivalent of set -e -o pipefail

Setting shell: bash runs the shell with not only -e (aka -o errexit) but also -o pipefail:

• It allows a sequence of commands to retain a non-zero exit status through the pipeline (note: the subsequent commands will still however continue to execute).
• Due to being paired with -o errexit it will help exit the step potentially a little earlier when you have anything else that would run after but shouldn't when the pipeline encountered a failure. However the scope of -e / -o errexit is not always obvious, but it should generally be helpful.

jq vs gh api --jq and printf

There are some subtle differences to keep in mind functionality wise between the two.

Using gh api --jq instead of piping output into the actual jq command prevents leveraging jq -cer CLI options:

• -c / --compact-output (minified to single-line format), makes assignment to GITHUB_ENV / GITHUB_OUTPUT a bit easier.
• -e / --exit-status is useful when a value lookup would fail (returns a null value as fallback), allowing to instead fail the command (typically with exit status 1, but there are additional cases, see JQ docs).
  • NOTE: While this works for outputs of null, it also applies to boolean output false, only use this when you'd want to treat as a failure.
  • JQ does provide alternative functionality for more flexible control over error handling, which is compatible with gh api --jq (exit status is 1 instead of 5).
• -r / --raw-output will avoid quote wrapping an output value that is a JSON string (not relevant to outputs of arrays/objects that have nested string values).
  • NOTE: gh api --jq seems to output values similar to using this option, except null is also special handled to output a blank line instead (jq -er would still output null as null).

Similarly for printf:

• Using a subshell as an arg for printf that runs jq -c (to compact the JSON into a single-line) can't leverage jq --exit-status as printf will override the exit status with it's own.
  • A workaround is to use a variable assignment earlier, where using a subshell to assign the value is compatible as nothing else overrides the exit status. printf can then run separately and use the variable as an arg instead.
  • Alternatively with a pipe, jq command can be run prior and printf can then read the value in through stdin via "$(cat -)" as an arg instead.
• printf will always output the formatted string, even when it encounters an error. You may want to filter that string prevent/discard it from flowing through stdout:
  • grep with -v / --invert-match will exclude matches by a regex pattern, this will also trigger an exit status of 1 which can be useful if nothing else would have prior for an early exit.
  • printf -v MY_VAR enables this alternative: printf -v MY_VAR '%s=%s\n' 'key' 'value' && echo "${MY_VAR}"
    • The value is assigned to the variable MY_VAR instead of being emitted to stdout.
    • With -o pipefail in play, if there was any failure up to this point the && short-circuits preventing the append. That's also useful for printf formatting features when they emit errors (like %d being provided an invalid value).
    • NOTE: The -v MY_VAR approach won't catch the null values like grep would, which is still relevant for object values output from jq. It can be still be useful for validation of args that are a number with %d.

Better error handling examples

We end up with a pipeline of commands like this:

# REST:
# NOTE: The grep regex will filters out any null assignment.
gh api search/issues --method GET --field "q=${SEARCH_QUERY}" \
  | jq -cer "${JQ_REST}" \
  | printf '%s=%s\n' 'pr_number' "$(cat -)" \
  | grep --invert-match '^[^=]*=null$' \
  >> "${GITHUB_OUTPUT}"

# GraphQL:
# NOTE: The grep regex is also used to catch null assignment in JSON fields,
# depending on field contents it may trigger false positives.
gh api graphql --field "filter=${SEARCH_QUERY}" --raw-field "query=${GQL}" \
  | jq -cer "${JQ_GQL}" \
  | printf '%s=%s\n' 'pr' "$(cat -)" \
  | grep --invert-match '[=:]null' \
  >> "${GITHUB_OUTPUT}"

Error handling side effects

This extra error handling can better communicate the step as failed, but note how this affects outputs.

A future step in the job might reference those outputs via env assignment for example. That is not an issue for direct outputs with single values - but when the value is parsed from a JSON field via fromJSON(), the error isn't too friendly when that object is missing:

Error: The template is not valid. .github/workflows/my-workflow-run.yml (Line: 72, Col: 22): Error reading JToken from JsonReader. Path '', line 0, position 0

If the step creating these outputs doesn't fail when the expected output value it creates would be invalid (aka null), a future step that references that output will continue to run - even if the outputs weren't created (or they were but the value assigned was null or equivalent).

Referenced outputs that don't actually exist will be null, so for both scenarios you could add a conditional guard before the step runs:

# Either of these approaches works:
if: env.PR_NUMBER != null && env.PR_BRANCH != null && env.PR_HEADSHA != null

# Iterating through an array of values to check for null is a bit awkward,
# empty string elements will match as `null`:
if: ${{ !contains(fromJSON(format('["{0}","{1}","{2}"]', env.PR_NUMBER, env.PR_BRANCH, env.PR_HEADSHA)), null) }}

That unfortunately won't work when those env were referencing values expected from a JSON object when it's missing, as fromJSON() needs to succeed while pre-processing the workflow job step to be run.

Further improvements

This JQ filter adds a conditional check over each top-level key of the object input (from the previous pipe), ensuring an error message is sent to stderr when any value is null.

• NOTE: For gh api --jq the error will result in an exit status of 1, but for jq it'll be 5.
• If no error is thrown, then the object is output as a single-line string with pr= as the prefix.

This removes the need for grep and printf commands, since nothing will go through stdout (when an error is encountered) to append >>.

JQ_GQL='
  .data.search.nodes[0]
  | { number, head_branch: .headRefName, head_sha: .headRefOid }
  | if (to_entries | any(.value == null)) then
      error("An expected value is missing: \(.)")
    end
  | "pr=\(.)"
'

gh api graphql \
  --field "filter=${SEARCH_QUERY}" \
  --raw-field "query=${GQL}" \
  --jq "${JQ_GQL}" \
  >> "${GITHUB_OUTPUT}"

Likewise, printf could also be avoided for formatting key/value pairs to append individual fields to $GITHUB_OUTPUT, removing the need for fromJSON() or explicit key/value assignment:

# The third line converts the object into an array of key/value objects,
# then outputs each kv pair as string, one per line.
# NOTE: Use with `gh api --jq` or `jq -r` to avoid quote wrapping output lines.
JQ_GQL='
  .data.search.nodes[0]
  | { number, head_branch: .headRefName, head_sha: .headRefOid }
  | to_entries[] | "\(.key)=\(.value)"
'

gh api graphql \
  --field "filter=${SEARCH_QUERY}" \
  --raw-field "query=${GQL}" \
  --jq "${JQ_GQL}" \
  | grep --invert-match '^[^=]*=null$' \
  >> "${GITHUB_OUTPUT}"

NOTE: While printf '%s=%s\n' $(cat -) could achieve a similar formatting output, cat would split by white-space when run via subshell (without quote wrapping).

• Thus if any value has white-space it'd unintentionally be split into multiple args.
• xargs --delimiter '\n' printf '%s=%s\n' is a more reliable alternative to cat, it's default arg splitting logic without --delimiter also differs from cat (but still splits by white-space).

---

Combined examples

Combined we have both formatting and error handling self-contained within the jq filter (thus also compatible with gh api --jq):

# Slightly simpler for single field:
JQ_GQL='
  .data.search.nodes[0]
  | if (.number == null) then error("Value should not be null") end
  | "pr_number=\(.number)"
'

# Multiple fields:
JQ_GQL='
  .data.search.nodes[0]
  | { number, head_branch: .headRefName, head_sha: .headRefOid }
  | if (to_entries | any(.value == null)) then
      error("An expected value is missing: \(.)")
    end
  | to_entries[] | "\(.key)=\(.value)"
'

gh api graphql \
  --field "filter=${SEARCH_QUERY}" \
  --raw-field "query=${GQL}" \
  --jq "${JQ_GQL}" \
  >> "${GITHUB_OUTPUT}"

# Outputs are now individual fields instead of single JSON object.

# Now when the prior step fails this step is skipped as expected,
# instead of throwing an error about `fromJSON()` due to the missing object output.
- name: 'Verify outputs'
  env:
    PR_NUMBER: ${{ steps.pr-context.outputs.number }}
    PR_BRANCH: ${{ steps.pr-context.outputs.head_branch }}
    PR_HEADSHA: ${{ steps.pr-context.outputs.head_sha }}
  run: |
    echo "PR Number: ${PR_NUMBER} | PR Branch: ${PR_BRANCH} | PR SHA (latest commit): ${PR_HEADSHA}"

# Single field example.
# This alternative instead defers `null` detection to the consuming step of the output
# NOTE: `shell: bash` was dropped as it's only helpful when using bash pipelines with multiple commands.

steps:
  - name: 'Get PR number'
    id: pr-context
    env:
      GH_TOKEN: ${{ github.token }}
      # These two env values should match the earlier workflow example with them:
      SEARCH_QUERY:
      GQL:
    run: |
      JQ_GQL='.data.search.nodes[0] | "pr_number=\(.number)"'

      gh api graphql \
        --field "filter=${SEARCH_QUERY}" \
        --raw-field "query=${GQL}" \
        --jq "${JQ_GQL}" \
        >> "${GITHUB_OUTPUT}"

  - name: 'Verify PR number is valid'
    env:
      PR_NUMBER: ${{ steps.pr-context.outputs.pr_number }}
    if: env.PR_NUMBER != null
    run: |
      echo "PR Number: ${PR_NUMBER}"

[polarathene]

UPDATE: Sadly this gh search prs method uses REST search endpoint instead of the graphql one, so it's just as prone to secondary rate limits which for this endpoint specifically seem to be quite low.

---

Just a quick follow-up, as good of a resource as my past comment perhaps is for some, there is a specialized CLI command to do the equivalent with less: gh search prs

That works very similar to the gh pr view command, except you have more control over the search constraints + sort order for filtering results 😎

# Provide the commit short-hash as search content just like the prior `search` API endpoint query works
# The equivalent qualifiers used in my `SEARCH_QUERY` env in the prior comment are CLI options here.

$ gh search prs --repo docker-mailserver/docker-mailserver --json number --jq '.[0].number' 047ffd6
1661

• Just add --head, --sort updated (default --order is desc), --state open, etc when you expect potentially more than one result and need to refine the results returned.
• The response returned differs, it's an array of objects (effectively .data.search.nodes), you should be able to take the first one, but no results will not have an exit status of 1 like with gh pr view. You're also limited to fields for --json to request, which is less than the direct graphql query offers.

---

Full workflow_run example:

name: 'Docs Preview (run)'
on:
  workflow_run:
    workflows: ['Docs Preview (PR)']
    types:
      - completed

jobs:
  example:
    name: 'Find and comment on PR'
    runs-on: ubuntu-24.04
    # Min permissions required
    # PR read for `gh search prs` if repo is private to avoid error `gh: Resource not accessible by integration`
    # PR write for 2nd step `marocchino/sticky-pull-request-comment@v2`
    permissions:
      pull_request: write
    steps:
      # Query PR by the commit SHA that triggered this workflow via the `pull_request` triggered workflow
      - name: 'Get PR number for commit'
        id: pr-context
        env:
          GH_TOKEN: ${{ github.token }}
          PR_TARGET_REPO: ${{ github.repository }}
          PR_SHA: ${{ github.event.workflow_run.head_sha }}
        run: |
          gh search prs "${PR_SHA}" --repo "${PR_TARGET_REPO}" --json 'number' \
            --jq '"pr_number=\(.[0].number)"' >> "${GITHUB_OUTPUT}"

      # Since we kept the `jq` filter simple, the output may not always be valid when the step succeeds
      # A conditional guard in this step provides validation before running instead.
      - name: 'Comment on PR'
        if: env.pr_number != null
        env:
          pr_number: ${{ steps.pr-context.outputs.pr_number }}
          image: https://i.giphy.com/media/v1.Y2lkPTc5MGI3NjExN28xbXdlcXJ0aGo5a252ZzRqN2F5aTk2aWgya2tsM2Z4cmtobTJ2cSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/3owzVXoDN8iP0w3T68/giphy.gif
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          number: ${{ env.pr_number }}
          header: preview-comment
          recreate: true
          message: |
             :tada:
             ![It's working!](${{ env.image }})

---

NOTE: Like with the REST API in my prior comment, I have also observed that gh search prs can just as easily trigger the secondary rate limit:

HTTP 403: You have exceeded a secondary rate limit. Please wait a few minutes before you try again.
If you reach out to GitHub Support for help, please include the request ID <ID here>. (https://api.github.com/search/issues?<params here>)

• Interestingly that error references the REST endpoint /search/issues 🤔 (EDIT: Yep it uses the same REST endpoint by calling this => this => this)
• gh api graphql on a separate job would continue to run just fine, while this secondary rate limit was in cooldown.

It's unfortunate that this solution is affected by the REST API rate limit issue. gh pr view is not, but if it's own limitations are an issue you'll want to use gh api graphql

[Kas-tle]

Here is the response I received from GitHub support regarding the list associated PRs endpoint:

Thanks for providing the requested logs.

After further investigation, I found that we have an internal issue tracking similar reports from other customers regarding the behavior of the list pull requests associated with a commit API endpoint. I’ve added your report as a +1 to our internal tracking issue to ensure your voice is included.

In some cases, editing the body of the pull request can trigger a resynchronization, which may result in subsequent requests to the API endpoint returning the expected results.

There has been a recent improvement to this endpoint, but fully addressing the issue requires some architectural changes. At this time, we don't have a specific ETA for when this will be resolved.

We'll mark this ticket as "solved" since this issue is already being tracked internally. However, if you have any follow-up questions or need further assistance, feel free to reply, and the ticket will automatically reopen.

Thank you for your patience and understanding!

[21hs]

Esse problema ocorre porque, por motivos de segurança, o GitHub Actions limita as informações disponíveis no evento workflow_run quando a origem do PR é um repositório bifurcado (forked repo). Por padrão, ações que interagem com repositórios de terceiros são mais restritas para evitar possíveis abusos ou comprometimentos.

Aqui estão as informações principais e possíveis soluções:

Motivo do Problema
PR local no mesmo repositório: Atributos, como pull_request, estão disponíveis no contexto github.event porque o repositório é confiável.
PR de um fork: Algumas informações sensíveis, como detalhes completos do PR, não são passadas automaticamente no evento workflow_run, provavelmente por razões de segurança.
Possíveis Soluções
Usar o atributo workflow_run.head_repository:

Quando o PR vem de um fork, você pode usar github.event.workflow_run.head_repository para determinar o repositório de origem e recuperar informações adicionais via API REST.
Exemplo:

steps:

• name: Recuperar PR via API
  run: |
  curl -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}"
  https://api.github.com/repos/${{ github.event.workflow_run.head_repository.full_name }}/pulls
  Passar o número do PR como saída do primeiro workflow:

No workflow pull_request, defina o número do PR como uma saída (output) e use-o no workflow workflow_run.
Exemplo no workflow pull_request:

jobs:
build:
outputs:
pr_number: ${{ github.event.pull_request.number }}
steps:
- run: echo "PR_NUMBER=${{ github.event.pull_request.number }}" >> $GITHUB_ENV
No workflow workflow_run, capture essa saída:~

jobs:
process:
steps:
- run: echo "Número do PR: ${{ github.event.workflow_run.conclusion }}"
Acessar dados diretamente com a API do GitHub:

Se as informações esperadas no evento workflow_run estiverem ausentes, use a API para buscar os detalhes do PR diretamente:

curl -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}"
https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}
Dica Final
Se isso não atender ao fluxo desejado, você pode abrir um Feature Request no repositório do GitHub Actions para sugerir melhorias futuras. Por enquanto, o uso de saídas entre workflows ou da API são os caminhos mais robustos.

[ghostinhershell]

Hi @Thomas-Boi,

We’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.  You can read our updated Code of Conduct and the announcement for more details. Thank you for helping us maintain an authentic and beneficial space for everyone.