Output commit SHA when `gh pr merge` is successful

[aduh95]

Describe the feature or problem you’d like to solve

Currently there seems to be no way to get SHA of the resulting commit when landing a PR without falling back to a "manual" call.

Proposed solution

Add support for a flag that would allow users opt-in (or opt-out) of getting the commit SHA in the stdout.

Additional context

Currently here's what we use:

jq -n \
    --arg title "${commit_title}" \
    --arg body "${commit_body}" \
    --arg head "${commit_head}" \
    '{merge_method:"squash",commit_title:$title,commit_message:$body,sha:$head}' > output.json
cat output.json
if ! commit="$(gh api -X PUT "repos/${OWNER}/${REPOSITORY}/pulls/${pr}/merge" --input output.json --jq 'if .merged then .sha else halt_error end')"; then
    pr_merge_failed "$pr" # Handle the failed merger
fi
# Use the final commit SHA
gh pr comment "$pr" --body "Landed in $commit"

[williammartin]

Hey @aduh95,

Thanks for the issue and the use case. Typically, for some data like this, we would expose fields via the --json flag, allowing programmatic access to the API responses. One of the challenges here is how to expose something like that given that pr merge also supports --auto (setting the commit to asynchronously merge when it is ready), or it can be merged asynchronously via the Merge Queue.

In these cases, --json sha would have no meaning. We don't have any precedence for dynamic --json values, and in the case of the Merge Queue, we don't even know at command invocation time (unlike --auto) whether the values will be valid or not. Not really sure what do about this.

In terms of existing support that is a little more native, I think it's possible to obtain the sha from pr view. For example:

gh pr merge --squash --subject ... --body ... ... <PR>

And after merging:

gh pr view <PR> --json mergeCommit --jq .mergeCommit.oid

Let me know if this helps, and if you have any other ideas on how we might expose better first class support for such a feature.

[aduh95]

I understand the struggle, making an additional API call for this would feel like a waste though 🤔 I can suggest creating an ad-hoc flag for that (e.g. gh pr merge --outputCommitSHAIfAvailable --squash --subject ... --body ... ... <PR>), though I would understand if that's too niche of a use-case to justify it. In any case, it would probably make sense to document the limitation (that the API response is not / can not be accessible)