Skip to content

Conversation

@cristiand391
Copy link
Contributor

@cristiand391 cristiand391 commented Jun 21, 2021

This PR adds JSON export functionality to gh run list and gh run view:

Examples:

ghd run list -L 1 --json headSha,headBranch,workflowDatabaseId,databaseId

[
  {
    "databaseId": 1227385157,
    "headBranch": "run-json-format",
    "headSha": "6ab9ab8a3c113afa459e9acae393ac35ecc68d85",
    "workflowDatabaseId": 25016
  }
]

ghd run view 964177659 --json headSha,headBranch,workflowDatabaseId,databaseId

{
  "databaseId": 964177659,
  "headBranch": "draft-flow-gh-repo-edit",
  "headSha": "055bf84069f8e83986e215c388de2af45e65b0a9",
  "workflowDatabaseId": 1208059
}

Closes #3477

@cristiand391 cristiand391 marked this pull request as ready for review June 23, 2021 17:41
return e
}
return e
})
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When building gh, all subcommands inherits the root's FlagErrorFunc declared here:

cmd.SetFlagErrorFunc(rootFlagErrorFunc)

But when testing a specific cmd isolated there's no Parent cmd so it panics when doing an error-check test like this:
https://github.com/cli/cli/runs/2876079048#step:5:94
(You can see it by adding an error-check test to any command that exports JSON like repo list, pr view, etc).

I've added this check to avoid accessing c.Parent if it doesn't exists, though I'm not sure if there's any better solution for this.

Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks great! My last, but very important request is that we think about which fields do we expose and resolve the inconsistency between IDs returned in this JSON payload vs IDs returned from payloads in other gh commands.

Comment on lines 54 to 55
"id",
"workflowId",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In --json output for some other commands, id and somethingId fields return GraphQL IDs because most of our data comes from GitHub API v4. However, in this case, information comes from GitHub API v3 (REST API) and so these IDs will be numeric database IDs. The different style and usability of these IDs makes me think that we should name these fields differently to avoid confusion. 🤔

What do you think about databaseId and workflowDatabaseId?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense 👍🏼, GitHub API v4 also refers to db IDs as databaseId in nodes so will go with that.

@mislav mislav self-assigned this Jul 27, 2021
@mislav mislav added the enhancement a request to improve CLI label Aug 4, 2021
@karuppiah7890
Copy link

Is this feature being built? :D I was thinking about doing a tiny automation using the gh run list command and noticed it didn't have the --json flag. I guess I could use the GH API for now

@cristiand391
Copy link
Contributor Author

Hi @karuppiah7890, will see if I can update this PR this weekend :)

@cristiand391 cristiand391 requested a review from mislav September 12, 2021 21:37
@kirillkorneevcb
Copy link

Any ETA on when this will be merged?

@cristiand391 cristiand391 requested a review from a team as a code owner December 17, 2021 15:46
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your patience!

@mislav mislav enabled auto-merge (squash) December 17, 2021 15:48
@mislav mislav merged commit ddaef8b into cli:trunk Dec 17, 2021
@cristiand391 cristiand391 deleted the run-json-format branch December 18, 2021 02:12
@kirikorneev
Copy link

@cristiand391 any chance of you adding HeadCommit/commit message as a json field? filtering on it is quite important in our workflow

@cristiand391
Copy link
Contributor Author

Hey @kirikorneev! Sorry for the delayed response, it seems the Run struct already defines a HeadCommit field but it isn't exposed as a json field yet.

The field headCommit should be added to this array, that way the --json flag will take that value and the export data method will add it to the json object.
Keep in mind that the type of the HeadCommit only exposes a Message field, that's the one you are requesting but if you need the whole head_commit object that the API provides you will need to add those fields here:

type Commit struct {

Could you please open a new issue in this repo? That way you can get feedback/approval from the maintainers to add expose this new field.

Thanks!

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

Labels

enhancement a request to improve CLI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow --json on the run command

8 participants