-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Remove Internal
from gh repo create
prompt when owner is not an org
#9465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
74b9724
Remove `Internal` from `gh repo create` prompt when owner is not an org
jtmcg 3c19d28
Refactor prompter with test coverage
jtmcg 396c1af
Add failing tests to check for error with internal vis in non-org repos
jtmcg b652a0e
Add Exclude to httpmock registry and implement in Test_repoCreate
jtmcg 95b8387
Add error if user attempts to create repo with --internal flag
jtmcg baae645
Add testing for error messages in gh repo create
jtmcg File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How readily can this new capability be reasoned in context of
httpmock
?This is the question I mentally keep coming back to reading and re-reading through this updated
registry
code. Depending how accurate I am below, maybe some added documentation and/or renaming makes sense:Tests that
Register
stubs are ensuring that specific HTTP requests are being made for REST or GraphQL APIs when the test callsVerify
after being deferred. It in turn iterates over all the stubs registered, finds whether any stubs have not been matched, and errors appropriately.Exclude
now changes this dynamic by including stubs that cause the test to fail if encountered. Less of aExclude
and more of aFailIf
scenario in my mind.Lastly, I don't know if
exclude
field is actually needed if anExclude
ed stub will be marked asmatched
inRoundTrip
:cli/pkg/httpmock/registry.go
Lines 64 to 83 in 95b8387
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately this is required because
Verify
will complain for any unmatched stubs.There's another implementation I tried that adds an
excludedStubs []stub
key/value to theRegistry
struct, but I tinkered with that for a long time and the looping and exiting of the tests weren't very user friendly. There ended up being extra log dump to parse for the Exclusion failure that was bad UX and theexclude
field is where I landed.First, names are hard 😅 I'd love to figure out what best to name this 📛
That said, I think
Exclude
isn't bad because technically we're callingregistry.Exclude
when we use this - it's just shortened tor.Exclude
in many of these tests (it can be confusing because we're shortening the name of the registry. Shortening the names of receivers and variables in golang is one of the things I take exception to in Golang practices for precisely this reason). So really our interface is:Taken all together, you either "register" and api call "exclude" an api calls.
I'm not sure if
FailIf
fits that well. I'm open to other suggestions.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes they are!
Putting aside whether to change the name of this or not, I primarily wanted to make sure I was following what this intended.
Because there is little to no documentation around the
httpmock
package, it causes the reader to read the code and infer the intention rather than clearly calling out what it does with documentation. So I'm making sure I understand its use first 👍My question about whether the
exclude
field was needed or not was because it seemed like the excluded stubs were still marked as matched, but I trust you; just unclear how that 1 additional field changes anything assuming everything is marked matched.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, gotcha. Yeah, your understanding is correct, but I'll add one piece that I think will help solidify this
When a match is found (and before anything errors), it also runs the provided callback, called
Responder
, on the stub. I've leveraged this so that the callback is hardcoded for theExclude
method so that when the match is found the callback that is invoked results in a failing test. That way I can avoid relying on errors to communicate that an excluded endpoint was called. This is important because testing for errors is a common pattern throughout the code (see wantErr)