Repository navigation
gh pr comment --edit-last now creates if no previous comment #10580
Description
Activity
👋 Hey @broksonic21, thanks for the ping ❤ I'm discussing this more with the team.
Sorry for this friction; I don't think we were aware of that issue from the previous maintainers when we accepted this feature request.
This means we can no longer use it or expect it to fail if there's no previous comment, which is breaking many of our flows from github actions - it's commenting when we wouldn't expect
In the meantime, can you talk more about how you use this feature? Why do you have workflows that you expect to fail?
A sample workflow YAML that demonstrates this use-case would be helpful, if possible! 🙏
I think the issue stems from the change here: https://github.com/cli/cli/pull/10427/files#diff-f547f67beffa35c15f5f45b8e35f1a774abf6a6459949b9a2065cfa3ff1e54b6R96-R113
Previously: if
EditLastflag is used, return the result ofupdateComment. Simple. If this errors out for any reason, no comment is created.Now:
- If
EditLastflag is used, first check if the error returned is the "no user comments" error. If not that error, return whatever it is. - If the error is "no user comments", and if in non-interactive mode, the block will drop out and use
createCommentautomatically.
This is a change in behavior, which will automatically create a new comment if
--edit-lastis used in non-interactive mode. To match previous behavior, it should simply error out because the new--create-if-noneflag was not supplied. In other words, the--create-if-noneflag is logically defaulting totruein non-interactive mode.- If
@BagToad here's our use case:
We have some scenarios where we check some logic, then:
- If some action to take:
** a) comment on the PR always (either edit old comment or write new comment) - If no action to take (i.e. all clean):
** b) If old comment for that PR, update the old comment to say thanks.
** c) If no old comment, don't say anything - no value in commenting, and it's noise
We had been using
--edit-lastfor the b/c cases - as it updated if there, but didn't do anything if nothing there. that's what broke now and we started getting a ton of comments on our PRs because of thatWe can work around this with some
gh pr view --json commentsand some jq magic, then some if logic, but it turns a one-liner into a 10 line script each time.For example, here's a sample bash:
#!/bin/bash set -x # Enable echoing of commands # --- Configuration --- PR_NUMBER="$1" REPO_OWNER="$3" REPO_NAME="$4" if [ -z "$PR_NUMBER" ] || [ -z "$REPO_OWNER" ] || [ -z "$REPO_NAME" ]; then echo "Usage: $0 <PR_NUMBER> <REPO_OWNER> <REPO_NAME>" exit 1 fi REPO="$REPO_OWNER/$REPO_NAME" # --- Get PR Description --- PR_DESCRIPTION=$(gh pr view "$PR_NUMBER" --repo "$REPO" --json title -q .title) # --- Check Description --- if [[ "$PR_DESCRIPTION" =~ ^(chore|fix|feature)\(.*\) ]]; then echo "PR description matches conventional commit format." # This is what broke - it now always comments, whereas it didn't before gh pr comment "$PR_NUMBER" --repo "$REPO" --body "Thanks for using conventional commits!" --edit-last || echo "No previous comment to edit" # end this else echo "PR description does not match conventional commit format." # could use --create-if-none instead of the || format here gh pr comment "$PR_NUMBER" --repo "$REPO" --body "You need to use conventional commit format." --edit-last || gh pr comment "$PR_NUMBER" --repo "$REPO" --body "You need to use conventional commit format." fi(or in an action)
The part / example that broke is where I wrote
# This is what broke - it now always comments, whereas it didn't beforeI agree the create-if-none field is nice to be able to fix up the else clause, that said instead.
- If some action to take:
Acceptance Criteria
There shouldn't be any new AC than what was originally captured in #10370 (comment) outside of what was implied about issues and PRs with comments:
-
Given I have no comments on an existing PR
when I rungh pr comment [<number> | <url> | <branch>] --edit-last --create-if-none --body <body>(non-interactively)
then a comment is created instead of erroring -
Given I have no comments on an existing PR
when I rungh pr comment [<number> | <url> | <branch>] --edit-last(interactively)
then I am prompted that no comment exists and whether or not I'd like to create a new comment. If I select Y, then I have the same experience as though I rangh pr comment [<number> | <url> | <branch>] -
Given I have no comments on an existing PR
when I rungh pr comment [<number> | <url> | <branch>] --edit-last --create-if-none(interactively)
then I am told that no comments exist and I am creating a new comment. Then I have the same experience as though I rangh pr comment [<number> | <url> | <branch>] -
Given I have no comments on an existing issue
when I run any of the above scenarios usinggh issue comment
then I have get the same behavior as I would runninggh pr comment
(i.e. make suregh issue commentgets the same new functionality that's added togh pr commentby the above AC)
Existing
gh issue commentandgh pr commentexperiencesThe following is the same for both commands:
$ gh pr comment https://github.com/tinyfists/gh-nonsense-internal/pull/39 - Press Enter to draft your comment in vim... ? Submit? Yes https://github.com/tinyfists/gh-nonsense-internal/pull/39#issuecomment-2729974029 $ gh pr comment https://github.com/tinyfists/gh-nonsense-internal/pull/39 --edit-last - Press Enter to draft your comment in vim... ? Submit? Yes https://github.com/tinyfists/gh-nonsense-internal/pull/39#issuecomment-2729974029 $ gh pr view https://github.com/tinyfists/gh-nonsense-internal/pull/39 --comments Andyfeller/236 public content tinyfists/gh-nonsense-internal#39 Open • andyfeller wants to merge 5 commits into main from andyfeller/236-public-content • about 4 months ago +126 -28 • No checks Reviewers: copilot-pull-request-reviewer (Commented) No description provided copilot-pull-request-reviewer commented • Nov 15, 2024 Copilot reviewed 5 out of 8 changed files in this pull request and generated 1 suggestion. • .github/workflows/promote-release.sh: Language not supported • public/docs/README.md: Evaluated as low risk • .github/workflows/promote-release.yml: Evaluated as low risk Tip: Turn on automatic Copilot reviews for this repository to get quick feedback on every pull request. Learn more https://gh.io/copilot-code-reviews-docs andyfeller (Member) • 0m • Edited • Newest comment This is the first PR comment ... edited View the full review: https://github.com/tinyfists/gh-nonsense-internal/pull/39#issuecomment-2729974029 View this pull request on GitHub: https://github.com/tinyfists/gh-nonsense-internal/pull/39
Additionally, here's an example around the
--bodyflag, which is not the same as--body-file:$ COMMENT=$(cat << EOF This is a cmdsubst heredoc based comment EOF ) $ echo $COMMENT This is a cmdsubst heredoc based comment andyfeller@Andys-MBP:~ $ gh pr comment https://github.com/tinyfists/gh-nonsense-internal/pull/39 --edit-last --body $COMMENT https://github.com/tinyfists/gh-nonsense-internal/pull/39#issuecomment-2729974029 $ gh pr view https://github.com/tinyfists/gh-nonsense-internal/pull/39 --comments Andyfeller/236 public content tinyfists/gh-nonsense-internal#39 Open • andyfeller wants to merge 5 commits into main from andyfeller/236-public-content • about 4 months ago +126 -28 • No checks Reviewers: copilot-pull-request-reviewer (Commented) No description provided copilot-pull-request-reviewer commented • Nov 15, 2024 Copilot reviewed 5 out of 8 changed files in this pull request and generated 1 suggestion. • .github/workflows/promote-release.sh: Language not supported • public/docs/README.md: Evaluated as low risk • .github/workflows/promote-release.yml: Evaluated as low risk Tip: Turn on automatic Copilot reviews for this repository to get quick feedback on every pull request. Learn more https://gh.io/copilot-code-reviews-docs andyfeller (Member) • 27m • Edited • Newest comment This is a cmdsubst heredoc based comment View the full review: https://github.com/tinyfists/gh-nonsense-internal/pull/39#issuecomment-2729974029 View this pull request on GitHub: https://github.com/tinyfists/gh-nonsense-internal/pull/39
-
@broksonic21 @GriceTurrble : just made #10625 ready for review with fairly extensive testing changes around this
Thank you @andyfeller - tests match what I'd expect!
andyfeller/10580-edit-last-regression "features": {
"ghcr.io/devcontainers/features/github-cli:1": {}
}gh pr checkout 28065holiman:vuln_2023connmanager
Describe the bug
Prior to #10427, --edit-last didn't comment if there wasn't a previous comment. That seems to have changed with this, and now it creates (by default) if no comment.
This means we can no longer use it or expect it to fail if there's no previous comment, which is breaking many of our flows from github actions - it's commenting when we wouldn't expect
At least in 26.8.1
Affected version
gh version 2.68.1 (2025-03-06) https://github.com/cli/cli/releases/tag/v2.68.1Steps to reproduce the behavior
Try again with a previous gh version, it doesn't do this (as per the recommendation here for why it's asking for a different feature for this: #6790
Expected vs actual behavior
--edit-last behaviour shouldn't have changed, or else we need a flag to not have it create a comment
CC: @latzskim and @BagToad as the mergers of that PR. Sorry for the ping; if there's an alternate workaround to get back old behavior, let us know.