91eb34011c
* 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. |
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| api | ||
| build | ||
| cmd | ||
| context | ||
| docs | ||
| git | ||
| internal | ||
| pkg | ||
| script | ||
| test | ||
| utils | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yml | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
GitHub CLI
gh is GitHub on the command line. It brings pull requests, issues, and other GitHub concepts to the terminal next to where you are already working with git and your code.
GitHub CLI is supported for users on GitHub.com and GitHub Enterprise Server 2.20+ with support for macOS, Windows, and Linux.
Documentation
For installation options see below, for usage instructions see the manual.
Contributing
If anything feels off, or if you feel that some functionality is missing, please check out the contributing page. There you will find instructions for sharing your feedback, building the tool locally, and submitting pull requests to the project.
If you are a hubber and are interested in shipping new commands for the CLI, check out our doc on internal contributions.
Installation
macOS
gh is available via Homebrew, MacPorts, Conda, Spack, Webi, and as a downloadable binary including Mac OS installer .pkg from the releases page.
Note
As of May 29th, Mac OS installer
.pkgare unsigned with efforts prioritized incli/cli#9139to support signing them.
Homebrew
| Install: | Upgrade: |
|---|---|
brew install gh |
brew upgrade gh |
MacPorts
| Install: | Upgrade: |
|---|---|
sudo port install gh |
sudo port selfupdate && sudo port upgrade gh |
Conda
| Install: | Upgrade: |
|---|---|
conda install gh --channel conda-forge |
conda update gh --channel conda-forge |
Additional Conda installation options available on the gh-feedstock page.
Spack
| Install: | Upgrade: |
|---|---|
spack install gh |
spack uninstall gh && spack install gh |
Webi
| Install: | Upgrade: |
|---|---|
curl -sS https://webi.sh/gh | sh |
webi gh@stable |
For more information about the Webi installer see its homepage.
Flox
| Install: | Upgrade: |
|---|---|
flox install gh |
flox upgrade toplevel |
For more information about Flox, see its homepage
Linux & BSD
gh is available via:
- our Debian and RPM repositories;
- community-maintained repositories in various Linux distros;
- OS-agnostic package managers such as Homebrew, Conda, Spack, Webi; and
- our releases page as precompiled binaries.
For more information, see Linux & BSD installation.
Windows
gh is available via WinGet, scoop, Chocolatey, Conda, Webi, and as downloadable MSI.
WinGet
| Install: | Upgrade: |
|---|---|
winget install --id GitHub.cli |
winget upgrade --id GitHub.cli |
Note
The Windows installer modifies your PATH. When using Windows Terminal, you will need to open a new window for the changes to take effect. (Simply opening a new tab will not be sufficient.)
scoop
| Install: | Upgrade: |
|---|---|
scoop install gh |
scoop update gh |
Chocolatey
| Install: | Upgrade: |
|---|---|
choco install gh |
choco upgrade gh |
Signed MSI
MSI installers are available for download on the releases page.
Codespaces
To add GitHub CLI to your codespace, add the following to your devcontainer file:
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {}
}
GitHub Actions
GitHub CLI comes pre-installed in all GitHub-Hosted Runners.
Other platforms
Download packaged binaries from the releases page.
Build from source
See here on how to build GitHub CLI from source.
Comparison with hub
For many years, hub was the unofficial GitHub CLI tool. gh is a new project that helps us explore
what an official GitHub CLI tool can look like with a fundamentally different design. While both
tools bring GitHub to the terminal, hub behaves as a proxy to git, and gh is a standalone
tool. Check out our more detailed explanation to learn more.