Add a new IssueRepoInfo function that fetches only the fields needed
for issue creation (id, name, owner, hasIssuesEnabled, viewerPermission),
avoiding defaultBranchRef and other fields that require Contents:Read.
Also add StubIssueRepoInfoResponse helper to httpmock for testing.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Remove `Internal` from `gh repo create` prompt when owner is not an org
Closes#9464
Internal repos only exist for organizations, so when a user selects their
personal namespace to create a repo using `gh repo create`, `Internal`
should not be an option in the `Visibility` prompt.
This should avoid the additional quirk where if the user selects
`Internal` while creating a personal repo and then proceeds to add any
of the README, .gitignore, or LICENSE files prompted for later, the repo
will not error and instead get created as a `Public` repo. This has the
potential for a user to unknowingly leak sensitive info intended to go
into a non-public repo.
* Refactor prompter with test coverage
By extracting the repo visibility options to its own function,
getRepoVisibilityOptions, we're able to directly test the behavior
introduced with this change. This breaks the testing pattern established
here thus far, but may be a good example of the direction we should
explore for a future refactor.
* Add failing tests to check for error with internal vis in non-org repos
There is a bug in the code, currently, where a user repo can attempt to be
created as with `--internal` visibility flag when that is not an option
for non-org repos. It fails at the API level if the --gitignore,
--license, or --add-readme flags are not included, but silently falls back
to Public visibility if one of them is included.
Because this bug already existed, this commit adds the tests to ensure
that both scenarios described above are captured accurately by the test
suite. A fix for the latter scenario will be coming in a future commit
* Add Exclude to httpmock registry and implement in Test_repoCreate
Upon attempting to make the previous commit pass, I realized that it was
actually impossible to test what I wanted to. The tests in the previous
commit were behaving as expected given the bug that commit described, but
upon attempting to implement a solution I realized that the tests were
only testing the mocks and not the code functionality itself.
Essentially, when the code to fix the bug was implemented, the tests were
failing because the mocks required to test the buggy behavior were no
longer being called. To make the tests pass, I'd have to rewrite them, but
were I to remove the bug fix, the tests would no longer fail.
This pointed me to a gap in our httpmocks - the ability to intentionally
exclude api calls. The behavior I'm trying to test, here, is that we stop
executing when a certain condition is met, and therefore won't make any
subsequent api calls down the chain.
This implements the Exclude method on the registry such that it will fail
if an excluded api pattern is called. I have refactored the tests in
Test_repoCreate to use the Exclude mock for testing.
* Add error if user attempts to create repo with --internal flag
This was previously failing at either the API if no other flags were
included or falling back to creating a public repo if one of gitignore,
license, or add-readme were included.
* Add testing for error messages in gh repo create
In the previous commits, we've introduced a new error when a user tries to
create an Internal repo not owned by an organization. This adds tests to
verify that the error we are getting is, in fact, the one associated with
this use case and not some random error.
Closes#9274
This change addresses a bug where repository and repository environment variables are not being retrieved from the appropriate host, causing GHES users to fail without specifying `GH_HOST` to force `gh variable set` to do the right thing.
In addition, the tests for this command have been updated to check both github.com and GHES variations to ensure this works.
Allows multiple issues or PRs to be edited in parallel, and querying for shared fields once to reduce network requests.
Co-authored-by: Sam Coe <samcoe@users.noreply.github.com>
- show path to config file
- display token prefix
- refine how missing scopes are shown
Co-authored-by: Sam Coe <samcoe@users.noreply.github.com>
Co-authored-by: Mislav Marohnić <mislav@github.com>
If a 4xx server response lists scopes in the X-Accepted-Oauth-Scopes
header that are not present in the X-Oauth-Scopes header, the final
error messaging on stderr will now include a hint for the user that they
might need to request the additional scope:
$ gh codespace list
error getting codespaces: HTTP 403: Must have admin rights to Repository. (https://api.github.com/user/codespaces?per_page=30)
This API operation needs the "codespace" scope. To request it, run: gh auth refresh -h github.com -s codespace
This enforces strict separation between serialization structs used for
repository creation payload with respect to whether GraphQL or REST was
used. Before, a field added to a GraphQL payload would leak to REST
payload (and vice versa).
We no longer guess the head repository using heuristics; instead, we
present the user with the choice of pushable repositories and an
additional option to create a new fork.
The new `pr create --head` flag is available for the user to specify the
head branch in `branch` or `owner:branch` format and completely skip any
forking or auto-pushing checks.
This commit is another isolation refactor, this time for repo fork.
However, I got fed up with the --remote="true|false|prompt" style of
flags and took this opportunity to switch to a set of bool flags:
--remote and --clone
--no-remote and --no-clone
the string args were really non standard and confusing; with only two
bools it was impossible to tell when to prompt.
First, consolidate the functionality between `pr merge` and `pr
checkout` that resolves the default branch name of the base repo. With
an added bonus, the new approach avoids an API request when one isn't
necessary.
Then, ensure that checking out 3rd-party PRs will result in local branch
name such as `<owner>/<branch>` when the head branch of the repository
matches the default branch of the base repository. We already have had
code in place to take care of this, but it only took effect in the `pr
checkout <number>`-style invocation.
This adds a thread-safe RoundTripper that can be used for mocking HTTP
requests in tests. Incoming requests are matched based on their
contents, not the order the stubs were registered in.
