Skip to content

gh run list should support --pr <num> #10386

Description

@0xdevalias

Describe the feature or problem you’d like to solve

It would be helpful if gh run list supported something like --pr <num>, so that we could get the associated runs/checks with a PR without needing to separately figure out the associated branch; or to fetch all the data and then filter after the fact.

Proposed solution

It will improve the UX by allowing users to directly fetch info about runs related to a PR, without needing to think about the implementation details and multiple calls to figure out the appropriate associated branch/etc.

Additional context

Help text:

⇒ gh run list --help
List recent workflow runs.

Note that providing the `workflow_name` to the `-w` flag will not fetch disabled workflows.
Also pass the `-a` flag to fetch disabled workflow runs using the `workflow_name` and the `-w` flag.

For more information about output formatting flags, see `gh help formatting`.

USAGE
  gh run list [flags]

ALIASES
  gh run ls

FLAGS
  -a, --all               Include disabled workflows
  -b, --branch string     Filter runs by branch
  -c, --commit SHA        Filter runs by the SHA of the commit
      --created date      Filter runs by the date it was created
  -e, --event event       Filter runs by which event triggered the run
  -q, --jq expression     Filter JSON output using a jq expression
      --json fields       Output JSON with the specified fields
  -L, --limit int         Maximum number of runs to fetch (default 20)
  -s, --status string     Filter runs by status: {queued|completed|in_progress|requested|waiting|pending|action_required|cancelled|failure|neutral|skipped|stale|startup_failure|success|timed_out}
  -t, --template string   Format JSON output using a Go template; see "gh help formatting"
  -u, --user string       Filter runs by user who triggered the run
  -w, --workflow string   Filter runs by workflow

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

JSON FIELDS
  attempt, conclusion, createdAt, databaseId, displayTitle, event, headBranch,
  headSha, name, number, startedAt, status, updatedAt, url, workflowDatabaseId,
  workflowName

LEARN MORE
  Use `gh <command> <subcommand> --help` for more information about a command.
  Read the manual at https://cli.github.com/manual
  Learn about exit codes using `gh help exit-codes`

Activity

  1. 0xdevalias commented on Feb 7, 2025

    @0xdevalias
    Author

    My original use case for this was to get the checks associated with a PR, which I have just found I can do 'in reverse' with gh pr checks:

    ⇒ gh pr checks --help
    
    Show CI status for a single pull request.
    
    Without an argument, the pull request that belongs to the current branch
    is selected.
    
    When the `--json` flag is used, it includes a `bucket` field, which categorizes
    the `state` field into `pass`, `fail`, `pending`, `skipping`, or `cancel`.
    
    Additional exit codes:
      8: Checks pending
    
    For more information about output formatting flags, see `gh help formatting`.
    
    USAGE
      gh pr checks [<number> | <url> | <branch>] [flags]
    
    FLAGS
          --fail-fast          Exit watch mode on first check failure
      -i, --interval --watch   Refresh interval in seconds when using --watch flag (default 10)
      -q, --jq expression      Filter JSON output using a jq expression
          --json fields        Output JSON with the specified fields
          --required           Only show checks that are required
      -t, --template string    Format JSON output using a Go template; see "gh help formatting"
          --watch              Watch checks until they finish
      -w, --web                Open the web browser to show details about checks
    
    INHERITED FLAGS
          --help                     Show help for command
      -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format
    
    JSON FIELDS
      bucket, completedAt, description, event, link, name, startedAt, state, workflow
    
    LEARN MORE
      Use `gh <command> <subcommand> --help` for more information about a command.
      Read the manual at https://cli.github.com/manual
      Learn about exit codes using `gh help exit-codes`

    So if implementing a gh run list --pr <num> or similar is too hard, maybe even a short note suggesting that it can be done with gh pr checks or similar would be sufficient to improve the UX/discoverability here.

  2. BagToad commented on Feb 7, 2025

    @BagToad
    Member

    👋 Hey @0xdevalias - thanks for this.

    So if implementing a gh run list --pr <num> or similar is too hard, maybe even a short note suggesting that it can be done with gh pr checks or similar would be sufficient to improve the UX/discoverability here.

    Good catch ✨ If gh run list --pr would be functionally equivalent to what currently exists with gh pr checks, I'm inclined to go the documentation route and add a note to gh run list.

    Can you think of any reason why we'd want to have both, or how the proposed gh run list --pr might be different from gh pr checks?

  3. self-assigned this
    on Feb 7, 2025
  4. BagToad commented on Jul 10, 2025

    @BagToad
    Member

    A gentle bump on this @0xdevalias; please let me know if you still think this might have value 🙏

  5. 0xdevalias commented on Jul 19, 2025

    @0xdevalias
    Author

    A gentle bump on this

    @BagToad Sorry, this totally slipped off my radar!


    If gh run list --pr would be functionally equivalent to what currently exists with gh pr checks, I'm inclined to go the documentation route and add a note to gh run list.

    Can you think of any reason why we'd want to have both, or how the proposed gh run list --pr might be different from gh pr checks?

    @BagToad While I haven't deeply explored this in quite a while and my memory of the deeper specifics is hazy; I think that a documentation / help text hint towards how to achieve it with the existing command is probably good enough.

    If I (or someone else) find some future reason why that approach isn't sufficient, we can always open a new issue more specifically focussed on that use case / details.

  6. BagToad commented on Aug 1, 2025

    @BagToad
    Member

    Thank you @0xdevalias and no worries 🙏

    I opened up #11434 to make the next steps more concise. I'll close this issue out and defer to that other one 🙇

    Appreciate you opening this and the discussion!

  7. 0xdevalias commented on Aug 4, 2025

    @0xdevalias
    Author

    I opened up #11434 to make the next steps more concise. I'll close this issue out and defer to that other one 🙇

    Appreciate you opening this and the discussion!

    @BagToad Sounds good, thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementa request to improve CLImore-info-neededMore info needed from user/contributorneeds-triageneeds to be reviewed

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions