A recent refactor caused the API for ReadBranchConfig to change, resulting
in changes for its consumers. Additionally, there was a large refactor of
the tests associated with ReadBranchConfig and its consumers to gain
confidence in this refactor. This commit attempts to resolve the
conflicts between the refactor and this effort as well as massage the
changes introduced here to reflect the refactor.
The refactor PR can be found here: https://github.com/cli/cli/pull/10197
I'll note that there are still a few failing tests in status_test.go. I
haven't had a chance to fully grok while they are failing, yet, and
suspect that some insights from the original PR author may be helpful
here.
Full disclaimer: I haven't verified any of this is working locally yet.
My primary motivation is to get these new changes working together in a
manner that unblocks further iteration on this effort.
* trunk: (79 commits)
Enhance help docs on ext upgrade notices
chore: fix some function names in comment
Expand docs on cleaning extension update dir
Simplifying cleanExtensionUpdateDir logic
Separate logic for checking updates
Capture greater detail on updaterEnabled
Restore old error functionality of prSelectorForCurrentBranch
Change error handling on ReadBranchConfig to respect git Exit Codes
fix: add back colon that I removed
fix: actually read how MaxFunc work and simplify the code
fix: padded display
Collapse dryrun checks in ext bin upgrade
Bump github.com/mattn/go-colorable from 0.1.13 to 0.1.14
Rename test user in tests
Change pr number in test
Surface and handle error from ReadBranchConfig in parseCurrentBranch
Directly stub headBranchConfig in Test_tryDetermineTrackingRef
Refactor error handling in ReadBranchConfig to avoid panic
Refine error handling of ReadBranchConfig
Add test for empty BranchConfig in prSelectorForCurrentBranch
...
- update `gh help environment` to include that upgrade notices only happen when gh or extensions are executed
- update `gh ext --help` to include reference to upgrade notices and points to `gh help environment` for info on disabling
This function was doing some unnecessary heavy lifting detecting if the directory being deleted actually existed when `os.RemoveAll()` would handle directories that exist or not.
During discussion in cli/cli#9934, we can to the conclusion that the logic around checking for core GitHub CLI updates would diverge from GitHub CLI
extension updates over time. To that end, this commit splits that logic into a separate function with a new environment variable.
This commit expands the in-line docs around updaterEnabled package variable used to affect release checking.
Along with clarifying specific details discovered when talking with @williammartin, I'm also removing a useless local variable.
Before this refactor, the errors emitted by ghrepo.FromURL and
rem.FindName() were suppressed. It isn't clear whether this was
intentional or not, but we've made the decision here to maintain the
original error behavior while still refactoring the return values for more
clarity. I've left a comment at each error handling block to explain this
decision.
Additionally, I've added the necessary git command stubs to the other
tests in status_test.go so that the tests are now passing.
I've only added the one test for parseCurrentBranch because the function
appears to be largely exercised by TestFind. There's definitely an
opportunity for a bigger refactor of the tests, here, but I want to avoid
scope creep as I propagate the ReadBranchConfig api changes throughout the
codebase
cmd.Output() will return an error when the git command ran successfully
but had no output. To handle this, we can check Stderr, as we expect it to
be populated for any ExitErrors or otherwise when there is a command
failure.
This allows for propagation of this error handling up the call chain, so
we are now returning errors if the call to git fails instead of just
handing off an empty BranchConfig and suppressing the errors.
Additionally, I've removed some more naked returns that I found in
pkg/cmd/pr/create.go createRun
Relates #10202
While we figure out how to handle consistent experience using templates for creating issues and PRs, let's correct the help usage for issue template flag use as this is the issue template name, not filename.
Replace the git config argument in prSelectorForCurrentBranch with
the branchConfig it was used to fetch. The tests needed to be refactored
accordingly to support this change to the prSelectorForCurrentBranch API.
In addition, I've moved the test to a table test format so I can expand
the test coverage in the next commit.
I think I went too far with my previous refactor and am backing out of it.
Adding a private readBranchConfig method on the client wasn't providing
any real additional value, so I've put it back into ReadBranchConfig.
However, I think there is still value in having parseBranchConfig
(formerly createBranchConfig) as a separate util function, as it both
improves readability of ReadBranchConfig and makes parsing its purpose
easier through the bespoke tests for it.
