* deletion for issues with confirmation flag
* add handling for interaction case
* finish implementation for issues
* finish the implementation for issues
* finalize the implementation for PR
* fix missing --yes flag for PR
* address PR comments related to feedbacks
* improve CommentablePreRun for pre checks
* improve confirmation prompt and truncate long comment body
* address PR comments on tests
* Truncate comment for confirmation prompt
Signed-off-by: Babak K. Shandiz <babakks@github.com>
* Improve test case descriptions
Signed-off-by: Babak K. Shandiz <babakks@github.com>
* Fix mock comment body
Signed-off-by: Babak K. Shandiz <babakks@github.com>
* Remove irrelevant prompt stub
Signed-off-by: Babak K. Shandiz <babakks@github.com>
* Use `opts.Interactive` as TTY indicator
Signed-off-by: Babak K. Shandiz <babakks@github.com>
* Fix expected `Interactive` value
Signed-off-by: Babak K. Shandiz <babakks@github.com>
* Polish `TestNewCmdComment`
Signed-off-by: Babak K. Shandiz <babakks@github.com>
---------
Signed-off-by: Babak K. Shandiz <babakks@github.com>
Co-authored-by: Babak K. Shandiz <babakks@github.com>
This commit converts all of the places using ColorScheme.Gray and ColorScheme.Grayf to Muted and Mutedf.
There is a little extra tidying up with local variable names or converting code to use Mutedf format.
There is still a bit of work to get the gh pr comment tests in order, however this goes a way towards fixing the issue along with acceptance tests.
Also, it turns out some of the issue acceptance tests were really running `pr` tests.
Due to the refactor of BranchConfig, the tests for `pr create` no longer
require a handful of stubbed git commands.
Additionally, I noticed some overlap between `pr create`'s existing logic
with the new finder code. I suspect that the finder's new ParsePRRefs
helper could be leveraged here as well, which would allow us to respect
non-centralized workflows pr create in the same way we are respecting them
in `gh pr view` and `gh pr status`
There was a lot of copy-pasta code between the finder and pr status. After
some investigation it was clear that the prSelectorForCurrentBranch code
was really just a duplicate of the finder's code without actually making
the API call for the PR. Since the ParsePRRefs helper had already
extracted much of the logic for determining a PR's head ref branch, I was
able to reuse it in gh pr status with a small refactor.
I've been struggling horribly to reason through all of this code, and
after much mental gymnastics I identified the culprit as the overloaded
"branch" string returned by parseCurrentBranch.
This value was either the name of the branch that the PR we're looking for
is associated with, or that name prepended with the owner's name and a :
if we're on a branch, so:
PR branch: featureBranch
branch == "featureBranch"
If on Fork belonging to "ForkOwner"
branch == "ForkOwner:featureBranch"
Since this extra information was bundled up into this single string, it
complicated the responsibilities of parseCurrentBranch's "branch" return
value. Thus, I've teased out "branch" into the new PRRefs struct:
type PRRefs struct{
BranchName string
HeadRepo ghrepo.Interface
BaseRepo ghrepo.Interface
}
This allows the new parsePRRefs function to move all the previous
"branch" string's information into structured data, and allows for a new
method on PRRefs, GetPRLabel(), to create the string that "branch"
previously held to pass into its downstream consumer, namely
findForBranch.
This also allowed for better test coverage, directly connecting the PRRefs
fields to the values contained in the git config. Overall, I am now
confident that this is doing what its supposed to do with respect to my
understanding of the various central and triangular git workflows we are
addressing.
