{{ message }}
Repository navigation
pr create function lacks json output #6366
Description
For automation work it's important to be able to read the created pr number to be passed into the auto merge enable command
gh pr create --head "hadata --base master --body "automation" --title "latest version"
gh pr merge --auto --squash 40 <-- no stable way to read this number, than relying on parsing the URL outputProposed solution
number=$(gh pr create --head "hadata --base master --body "automation" --title "latest version" --json number)
gh pr merge --auto --squash $numberI have already raised a PR as the proposed solution, it has a slight issue with backward compatibility because of the -t flag being used in both JSONARGs and in the pr create request, for now I have renamed the pr create short arg as -T
Additional context
Here is the PR #6365
i will have to close it and reopen from my org account, because until we come to a conclusion on this, i want to be able to distribute the modified version of gh to my GitHub runners
Activity
vilmibm commentedon Sep 29, 2022
Outputting JSON from
gh pr createis intriguing, and something that we have discussed in the past. We decided not to default to it as that seemed too opinionated, hence just outputting the URL.I argue that the current approach of printing a URL is stable: GitHub is not going to suddenly change the URL format for how to go to a PR as that would seriously disrupt a convention going back to the earliest days of the platform and break untold megabytes, if not gigabytes, of
bashscripts universe wide.That said, it's completely reasonable to want to programmatically operate on a PR that was just opened, so I am sympathetic to the desire to output JSON in general from this command.
I just did a quick grep and, as far as I can see, we do not ever use the JSON
Exporterfor commands that perform mutations (someone please correct me if I'm wrong). For that reason, it's already premature to just makepr createmirrorpr list, for example. TheExporterwas definitely designed to use from "read only" commands and we'd need to evaluate how well it could serve us in this new context.Right off the bat, I do not like the contention around the
-tflag. I would, however, consider just a--jsonflag that outputs a set payload for the PR without customization.Marking this as
discussso the core team can go over it in our next planning meeting.devzer01 commentedon Sep 30, 2022
I understand your feedback, just adding --json using existing lib functions prevents code duplication, I am perfectly find if you feel that is this not necessary, but for a regular engineer who has been doing lot of dev ops related work in building pipelines . This is just a minor inconvenience, but from what i have seen in the code everything ultimately end up being a GraphQL calls , so i could just try to use that,
i am not new to grep see awk cut tr head tail etc, but i firmly believe with modern tools that already has json support it would be a matter of coming to an agreement,
you said you don't return json for the actions that mutate, what's the reason behind that? as far as the code is conserved you just add JSON formatting to the command area
Anyway i hope you guys can come to some alignment on this issue in your next meeting
thanks for receiving the PR
mislav commentedon Oct 6, 2022
In the PR thread we have decided that, for now, we will keep
--jsonsupport scoped to only list- and view-type commands. See #6367 (comment) for a workaround with passing the result ofgh pr createto other commands programmatically.