Describe the bug

You can't install the CLI from the .deb package on Ubuntu or other Debian based systems as of today because the GPG key used to sign the package has expired.

Steps to reproduce the behavior

1. Attempt to follow the debian installation instructions

Expected vs actual behavior

The apt update step fails with the following error:

W: GPG error: https://cli.github.com/packages stable InRelease: The following signatures were invalid: EXPKEYSIG C99B11DEB97541F0 Nate Smith <[email protected]>
E: The repository 'https://cli.github.com/packages stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Logs

You can see the key expired today if you examine it:

I'm pretty sure this is the same issue as #6174.

This looks awesome! Are you planning GHE support already?

Update from the GitHub CLI team:

In the README we shared additional information about this to help set expectations. Enterprise Server support is something we're really excited to provide, but we want to ensure it's actually usable and that the API endpoints are available on the GHES versions people are using.

Describe the bug

TLS handshake timeout error upon first ever run of gh issue list after having the CLI installed.

gh version 0.5.5 (2020-02-13)
https://github.com/cli/cli/releases/tag/v0.5.5

Steps to reproduce the behavior

1. brew install github/gh/gh
2. gh issue list
3. Authenticate via the URL provided.
4. Authentication complete. Press Enter to continue…
5. Retry gh issue list
6. Observe the error after ~10 seconds:

Post https://api.github.com/graphql: net/http: TLS handshake timeout

Expected vs actual behavior

I was expecting to see the list of issues for the current working directory's repo, however it ended up error-ing on me.

A browser is not always available for authentication.

I am working on a vagrant linux guest, which cannot open browser in the Windows host.

I would love to see a gh login command (or similar) to store credentials as appropriate by the system without opening a browser.

At the very least - if this is not changed, or until it is - I would love to see the URL it wants to open so I can open it manually.

This reverts commit 930ee60ac5895e4eb4e19a22bf34148b76a2d431 and uses the text.Truncate function from PR #3519 that correctly measures ANSI escape codes.

The gh repo create command right now has separate and potentially confusing behaviors when ran inside an existing local git repository vs. outside of it.

Bugs:

• [x] Remote origin already exists https://github.com/cli/cli/issues/2166 #893
• [x] Can't create a new repo while within a repo https://github.com/cli/cli/issues/2059
• [x] Takes parent directory instead of current directory name https://github.com/cli/cli/issues/2026
• [x] Confusing prompt This will create 'your-repo-name' in your current directory. Continue? (Y/n) #1913 #2180 https://github.com/cli/cli/pull/2295 https://github.com/cli/cli/pull/2214 https://github.com/cli/cli/pull/2507
• [ ] Do not offer INTERNAL visibility option if it's not supported on the platform https://github.com/cli/cli/issues/2106
• [ ] Have repo create pick up the default branch setting on GitHub #1810
• [x] Repo create: local directory for new repo not created when non-interactive and --confirm #2587

Features:

• [x] Ask to git init https://github.com/cli/cli/issues/2099 https://github.com/cli/cli/issues/1280
• [x] Specify the base dir for the new repo https://github.com/cli/cli/issues/2077
• [x] Create with gitignore and license files #1907
• [x] Expose more repository settings https://github.com/cli/cli/issues/995
• [x] After initializing a repo with a template pull down changes https://github.com/cli/cli/issues/2290

Ref. https://github.com/cli/cli/pull/547

Describe the bug

The MSI installer for Windows 10 x64

1. suggests a wrong install folder (x86 instead of x64)
2. ignores different install folder when changed by user

Tested with installer for 0.6.2: https://github.com/cli/cli/releases/download/v0.6.2/gh_0.6.2_windows_amd64.msi

Steps to reproduce the behavior

1. Launch .msi install file on Windows 10 x64.
2. See default install location: C:\Program Files (x86)\GitHub CLI (error 1)
3. Change install location to: C:\Program Files\GitHub CLI
4. Finish the install process.
5. See application installed in: C:\Program Files (x86)\GitHub CLI (error 2)

Expected vs actual behavior

1. Default install location to be: C:\Program Files\GitHub CLI
2. User changes to install location to be reflected

This is a tracking ticket listing all the filtering options for issues and pull request currently available on GitHub and the status of their availability in GitHub CLI. (Checked means implemented and merged to master.)

We do not plan to explicitly support all these filtering options in CLI. We will select those that we intend to implement on a case-by-case basis.

Filtering options available through GitHub web UI

Issues

• [x] assignee --assignee, -a
• [x] assigned to the current authenticating user
• [ ] no assignee
• [x] ~labels --label, -l ("OR" logic)~
• [x] labels --label, -l ("AND" logic) #419
• [ ] excluding a label
• [ ] no label
• [x] state --state, -s
• [x] author --author, -A #625
• [x] authored by the current authenticating user
• [x] mentioning user
• [x] mentioning the the current authenticating user
• [ ] mentioning team
• [ ] project
• [ ] no project
• [x] milestone
• [ ] no milestone

Pull requests

• [x] assignee --assignee, -a
• [x] assigned to the current authenticating user
• [ ] no assignee
• [x] ~labels --label, -l ("OR" logic)~
• [x] labels --label, -l ("AND" logic) #419
• [ ] excluding a label
• [ ] no label
• [x] state --state, -s
• [x] author --author, -A
• [x] authored by the current authenticating user
• [ ] mentioning {user|team}
• [x] mentioning the current authenticating user
• [ ] project
• [ ] no project
• [ ] milestone
• [ ] no milestone
• review status
  • [ ] no reviews
  • [ ] review required
  • [ ] approved
  • [ ] changes requested
  • [ ] reviewed by {user|team}
  • [ ] reviewed by the current authenticating user
  • [ ] not reviewed by {user|team}
  • [ ] not reviewed by the current authenticating user
  • [ ] awaiting review from {user|team}
  • [ ] awaiting review from the current authenticating user

Filtering options available through advanced search syntax

Issues

• [ ] commented on by {user}
• [ ] number of comments
• [ ] number of interactions
• [ ] number of reactions
• [ ] involves {user}
• [ ] linked issue/pull request
• [ ] date created
• [ ] date updated
• [ ] date closed

Pull requests

• [ ] commented on by {user}
• [ ] number of comments
• [ ] number of interactions
• [ ] number of reactions
• [ ] involves {user}
• [ ] linked issue/pull request
• [ ] date created
• [ ] date updated
• [ ] date closed
• [ ] date merged
• [ ] search by commit SHA
• [ ] draft status
• [x] base branch --base, -B
• [ ] head branch

Describe the bug

We are trying to upload artefacts created with our build server. We are uploading two files, one ~50Mb and the other ~90Mb. We can upload one or the other, but it takes 20 minutes to do so. If we try to upload both the process fails with http2: Transport: cannot retry err [stream error: stream ID 1; REFUSED_STREAM] after Request.Body was written; define Request.GetBody to avoid this error.

If I run the speedtest CLI tool the upload speed is nearing 100Mb/s, yet while the gh release create command is running it barely reaches 1Mb/s. If I use the website, the upload is very fast.

Our version is gh version 1.7.0 (2021-03-04).

Steps to reproduce the behavior

1. Type gh release create speed-test build1.tar.gz build2.tar.gz
2. Wait 20 minutes
3. Error appears

Expected vs actual behavior

The release should upload relatively quickly and the process should not fail.

Logs

  Starting: /opt/buildagent/temp/agentTmp/custom_script1786572503185520936
18:31:43
  in directory: /opt/buildagent/work/cd80fa15c4f3d102
18:51:31
  Post "https://uploads.github.com/repos/our-team/our-project/releases/release-id/assets?label=&name=our-file.tar.gz": http2: Transport: cannot retry err [stream error: stream ID 1; REFUSED_STREAM] after Request.Body was written; define Request.GetBody to avoid this error
18:51:31
  Process exited with code 1
18:51:31
  Process exited with code 1 (Step: Create GitHub release (Command Line))

Describe the feature or problem you’d like to solve

I used gh pr create (surprised that it defaulted to open my PR from a fork into the upstream repo - it was awesome🤩) and when I went to edit the PR body, it defaulted to nano but I'd prefer it to use vim.

Proposed solution

1. When a user first install gh prompt them to choose a default editor:

• nano
• vim

2. Let a user specify editor

gh set-editor vim

How will it benefit CLI and its users?

• it will support nano and vim users ❤️

Additional context

N/A

Describe the bug

I'm trying to use GH cli and at the first impression, I got an error

I have created a repository successfully (gh opened a web browser to login). However, when I want to clone the repository by the command gh repo clone, it requires me to enter username/password then I should use git clone instead. See my screenshot

Steps to reproduce the behavior

1. Enter command gh repo create <repo name>
2. GH required me to enter username/password

Expected vs actual behavior

I think it should clone the repo (even https or ssh) without entering username/password. (git command does it well)

Logs

 🐶 ~/code/unitest/UnitTestDemo  gh repo create NetCoreCLI
✓ Created repository voquanghoa/NetCoreCLI on GitHub
? Create a local project directory for voquanghoa/NetCoreCLI? No
 🐶 ~/code/unitest/UnitTestDemo  gh repo clone NetCoreCLI
Cloning into 'NetCoreCLI'...
Username for 'https://github.com': voquanghoa
Password for 'https://[email protected]':
 ✘  🐶 ~/code/unitest/UnitTestDemo  gh repo clone voquanghoa/NetCoreCLI
Cloning into 'NetCoreCLI'...
Username for 'https://github.com': ^C
 ✘  🐶 ~/code/unitest/UnitTestDemo  cat /Users/voquanghoa/.ssh/id_rsa.pub | pbcopy
 🐶 ~/code/unitest/UnitTestDemo  gh repo clone voquanghoa/NetCoreCLI
Cloning into 'NetCoreCLI'...
Username for 'https://github.com': ^C
 ✘  🐶 ~/code/unitest/UnitTestDemo  git clone [email protected]:voquanghoa/NetCoreCLI.git
Cloning into 'NetCoreCLI'...
Warning: Permanently added the RSA host key for IP address '13.250.177.223' to the list of known hosts.
warning: You appear to have cloned an empty repository.
 🐶 ~/code/unitest/UnitTestDemo  gh --version
gh version 0.10.1 (2020-06-24)
https://github.com/cli/cli/releases/tag/v0.10.1
 🐶 ~/code/unitest/UnitTestDemo  cd ..
 🐶 ~/code/unitest  gh repo clone voquanghoa/NetCoreCLI
Cloning into 'NetCoreCLI'...
Username for 'https://github.com':

Thanks for addressing #2090! I think the solution is great in terms of behavior, but perhaps the nomenclature could be better. In particular, as @mislav said here, referring to a "default repository" (which is implied by the command gh repo set-default is ambiguous. It would be clearer if the subcommand was e.g. git repo set-default-remote.

I also don't think the reference to "this directory" is an intuitive nomenclature. I tend to think of the directory containing a git repository as "the local repository", not as a generic directory. So I'd also suggest changing the phrasing in:

https://github.com/cli/cli/blob/6618baaf63cbae2eb4162082496f6171bb9b3fa3/pkg/cmd/repo/setdefault/setdefault.go#L63

https://github.com/cli/cli/blob/6618baaf63cbae2eb4162082496f6171bb9b3fa3/pkg/cmd/repo/setdefault/setdefault.go#L238

https://github.com/cli/cli/blob/6618baaf63cbae2eb4162082496f6171bb9b3fa3/context/context.go#L95

...to say e.g. "default remote for this repository".

Originally posted by @waldyrious in https://github.com/cli/cli/discussions/6777#discussioncomment-4491639

Describe the feature or problem you’d like to solve

Hello,

I want to discover a way to retrieve the open PRs and how many reviews each one has when I search them.

Is that possible?

I already checked the docs to find the solution, without success.

Proposed solution

What I want:

> gh search prs some_text --state=open
Showing 6 of 6 pull requests

BlaBla/blabla-ios      #1111 Some Awesome Change      3 approved reviews       about 2 minutes ago

What I get:

> gh search prs some_text --state=open
Showing 6 of 6 pull requests

BlaBla/blabla-ios      #1111 Some Awesome Change     about 2 minutes ago

Additional context

What I already tried without success:

> gh search prs some_text --state=open --json reviews
# seach json doesn't support reviews

> gh pr view 1111 --json reviews
# I can't only see the reviews for one PR and not for a brunch of them

Thanks in advance!

CLI Feedback

You can use this template to give us structured feedback or just wipe it and leave us a note. Thank you!

What have you loved?

How easy it is to create an extension!

What was confusing or gave you pause?

The output from gh extension create is:

Next Steps
- run 'cd gh-projects; gh extension install .; gh projects' to see your new extension in action
- use 'go build && gh projects' to see changes in your code as you develop
- commit and use 'gh repo create' to share your extension with others

I'd like to suggest separating the last item into two, as they are distinct steps. I failed to notice the first part of the line when scanning, and after creating a repo with gh repo create and trying to push to it, I encountered the following error:

$ git push
error: src refspec refs/heads/main does not match any

because my new repository didn't have any commits yet. This was confusing at first, and with the error git returns it is probably very confusing to new users.

This was completely user error, which I think would have been lessened if the commit step was on its own line, after repo creation.

Anything else?

As always, thank you! 🙏

Describe the feature or problem you’d like to solve

I'd like to be able to effectively click the "Sync fork" button in the GitHub web interface from the command line, without having to always type the name of one of the repos.

This is essentially issue #444 again, which gh repo sync was introduced (in #3813) to fix. However, I currently need to do the following:

1. gh repo set-default to the source repo (once).
2. gh repo sync <fork-repo> (every sync).

I'm fine with Step 1, but I don't want to remember/type the repo name repeatedly every time I do Step 2.

Proposed solution

I'd ideally like gh to keep track of two repos, the upstream and fork repos, just like the GitHub web interface already seems to. I'm not sure which one should be called the set-default repo. My intuition says that it's the fork repo that knows what it's forked from, so that would make more sense, but I normally want to access PRs and such from the upstream repo, not the fork...

Here are some different ideas for an interface:

1. gh repo sync --set-default ... (change future behavior of gh repo sync to use ... argument)
2. gh repo set-fork ... (if set-default sets the upstream repo)
3. gh repo set-upstream ... (if set-default sets the fork repo)

In any of the cases above, gh repo sync without any arguments would then sync from upstream to fork repo. I'm not actually sure what gh repo sync without arguments is supposed to do, because it just errors for me (on Windows 11):

[git.exe remote -v]
[git.exe config --get-regexp ^remote\..*\.gh-resolved$]
[git.exe remote -v]
[git.exe config --get-regexp ^remote\..*\.gh-resolved$]
⣾* Request at 2022-12-28 12:11:46.1605836 -0500 EST m=+0.359947801
* Request to https://api.github.com/graphql
⣻* Request took 286.184ms
[git.exe fetch -q upstream refs/heads/master]
⣾[git.exe rev-parse --verify refs/heads/master]
[git.exe rev-parse --symbolic-full-name --abbrev-ref master@{u}]
failed to run git: fatal: ambiguous argument 'master@u': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

Motivation

Working on a user's fork of a repo to submit PRs to a read-only repo (e.g. open-source project that the user does not have write access to) is extremely common. Syncing the main branch before starting a new PR is a necessary first step. Bringing the CLI into parity with the web interface would be great.

Describe the feature or problem you’d like to solve

Currently running gh pr comment --edit-last will fail if there is not an existing comment from the author. It would be nice to prompt users and/or allow users to use the option (or a new option) that will edit the last comment if it it exists but creates a new one if not.

❯ gh pr comment 5 --edit-last --body 'This is just a test'
no comments found for current user

Proposed solution

Add an additional option for gh pr comment such as --edit-last-or-create that will not fail if the user hasn't yet commented on the PR, it will simply create a new comment.

❯ gh pr comment 5 --edit-last-or-create --body 'This is just a test'
https://github.com/joe-sharp/<redacted>/pull/5#issuecomment-<redacted>

How will it benefit CLI and its users? Script writers will no longer need to worry about making a conditional to check if a comment exists before running the command. This is useful for commenting the results of a build or linting job without polluting the PR with multiple comments.

Additional context

Please let me know if additional context is needed, but this should be pretty straight forward.

Sometimes GitHub Actions messes up the file/repo permissions and we get the following error when running gh release create:

failed to run git: fatal: detected dubious ownership in repository at '/__w/busytex/busytex'
To add an exception for this directory, call:

	git config --global --add safe.directory /__w/busytex/busytex

It would be nice to have a shortcut option workaround in gh around it or a more specific error message. Currently I add chown $(whoami) -R . as additional command in my GitHub Actions run commands.