Open chriskrycho opened 9 months ago
Some other potentially-relevant info here—
Relevant section of my .gitconfig
:
[credential "https://github.com"]
helper =
helper = !/opt/homebrew/bin/op plugin run -- gh auth git-credential
Contents of ~/.config/op/plugins.sh
:
export OP_PLUGIN_ALIASES_SOURCED=1
alias gh="op plugin run -- gh"
That is sourced in my ~/.config/fish/config.fish
:
source /Users/chris/.config/op/plugins.sh
Contents of ~/.config/gh/config.yml
:
# What protocol to use when performing git operations. Supported values: ssh, https
git_protocol: https
# What editor gh should run when creating issues, pull requests, etc. If blank, will refer to environment.
editor:
# When to interactively prompt. This is a global config that cannot be overridden by hostname. Supported values: enabled, disabled
prompt: enabled
# A pager program to send command output to, e.g. "less". Set the value to "cat" to disable the pager.
pager:
# Aliases allow you to create nicknames for gh commands
aliases:
co: pr checkout
# The path to a unix socket through which send HTTP connections. If blank, HTTP traffic will be handled by net/http.DefaultTransport.
http_unix_socket:
# What web browser gh should use when opening URLs. If blank, will refer to environment.
browser:
version: "1"
Output of op plugin inspect gh
:
$ op plugin inspect gh
GitHub CLI
Configured Aliases
✔ Alias for "gh" configured
✔ Aliases sourced (/Users/chris/.config/op/plugins.sh)
Configured Credentials
✔ Configured as global default:
CREDENTIAL TYPE ITEM VAULT
GitHub Personal Access Token GitHub Personal Access Token Personal
I've also experienced this quite often, though with a different setup than @chriskrycho. In the cases where I've noticed the hanging behavior, I have just been running normal / standard gh
commands directly (e.g. gh pr create
or gh pr list
).
I just hit this behavior, and the actual command which is executing (per ps auxw
) is:
chris 46825 0.0 0.0 409266640 22240 s004 S+ 9:10PM 0:00.03 op plugin run -- gh repo create --private --source .
Since I don’t know what else to poke at, I’ll start with spindumps:
op plugin run
process:op daemon
process:And just for extra good measure, samples:
op plugin run
processop daemon
process@rwjblue I suspect you have a sourced plugins.sh
like the one I showed above, in which case any gh
invocation like gh pr create
is actually doing op plugin run -- gh pr create
.
Are there meant to be two helper =
in the .gitconfig or only one? I've experienced the hangs too and my config was like this:
[credential "https://github.com"]
helper =
helper = !op plugin run -- gh auth git-credential
[credential "https://gist.github.com"]
helper =
helper = !op plugin run -- gh auth git-credential
https://git-scm.com/docs/gitcredentials seems to indicate that each helper will be tried in turn.
I've just removed those two extra lines with nothing after the equals to see if I continue to experience hangs.
Since these plugins are written in Go you can send SIGQUIT (ctrl-) to the program and have it emit a stack dump. Here's mine from experiencing this bug today.
Looks like it's blocked on searchDefaultsFileInCurrentDirRecursively
. There's 5212 files in my current directory but it seems like it hangs indefinitely, so guessing there might be some bugs in that function, maybe to do with the fact that there's a bunch of symlinks in the .pixi
subdirectory.
Here's a repo that has my working directory in it: https://github.com/benmoss/op-gh-repro
Unfortunately it looks like this bug is in the op
CLI itself which is closed-source AFAIK. https://go.1password.io/op/op-cli redirects to https://gitlab.1password.io/dev/b5/op which is not public
Since these plugins are written in Go you can send SIGQUIT (ctrl-) to the program and have it emit a stack dump. Here's mine from experiencing this bug today.
Looks like it's blocked on
searchDefaultsFileInCurrentDirRecursively
. There's 5212 files in my current directory but it seems like it hangs indefinitely, so guessing there might be some bugs in that function, maybe to do with the fact that there's a bunch of symlinks in the.pixi
subdirectory.Here's a repo that has my working directory in it: benmoss/op-gh-repro
Unfortunately it looks like this bug is in the
op
CLI itself which is closed-source AFAIK. go.1password.io/op/op-cli redirects to gitlab.1password.io/dev/b5/op which is not public
I also found the same problem and reported it to the 1Password team via the support email about 2 weeks ago. They responded “I have reported this to my team for investigation, and we will do our best to resolve it as soon as possible for you”, but unfortunately, they have not resolved the issue yet.
The current workaround (that works on my machine) is:
/tmp
directory or anywhere outside your home directory.op plugin init service
and select "Use automatically when in this directory or subdirectories" if you prefer to work on volumes separate from your home directory.Hopefully, they can fix it one day or at least open-source this part and allow people to contribute to this component.
For 1Password engineer team, I am not sure if the support team forwards my patch to you. Let me paste the patch again:
After profiling the op
CLI, I found that searchDefaultsFilelnCurrentDirRecursively
under the plugin module attempts to traverse the parent directories and open files to locate the .op/plugins/<plugin>.json
file before falling back to the global configuration. However, this process can be slow due to the complexity of the parent directory structure.
As there is no needs to traverse the parents to find the .op
directory of the parent, I propose simplifying the searchDefaultsFilelnCurrentDirRecursively
function, which would take (the worst) $O(n)$ time, where $n$ is the depth of the current directory relative to the root. Unit tests should be added to this code, but I have tested it with some hanging cases in my directory.
package main
import (
"errors"
"fmt"
"os"
"path/filepath"
"strings"
)
func searchDefaultsFilelnCurrentDirRecursively(dir string, program string) ([]byte, error) {
dirToCheck := filepath.Clean(dir)
configFile := filepath.Join(".op", "plugins", program+".json")
for len(dirToCheck) > 0 {
configFilePath := filepath.Join(dirToCheck, configFile)
content, err := os.ReadFile(configFilePath)
if err == nil {
return content, nil
}
dirToCheck = dirToCheck[:strings.LastIndexByte(dirToCheck, byte(os.PathSeparator))]
}
content, err := os.ReadFile(filepath.Join("/", configFile))
if err == nil {
return content, nil
}
return nil, errors.New("no defaults found")
}
I have exactly the same issue. Running the gh
command outside /tmp
was the solution for me.
Platform or tool
GitHub
Desired or expected behavior
The
gh
plugin should have consistent behavior, always succeeding or failing in the same ways under the same conditions.Current behavior
The
gh
plugin semi-regularly “hangs” when invoked byop plugin run -- gh auth git-credential
in a[credential]
section in my.gitconfig
. It does not happen at predictable intervals or under predictable conditions, unfortunately. It only happens after triggering authentication with the 1Password UI, but it does not always happen after triggering that authentication.Relevant log output
No response
op CLI version
2.24.0