pr checkout <number> - no supported methods remain #262
Labels
No Label
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind
enhancement
kind
feature
kind/proposal
kind
question
kind
refactor
kind/security
kind/testing
kind/translation
priority/critical
priority/high
priority/low
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/has-backport
status/has-pull
status/needs-backport
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/sdk
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/tea#262
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Using current master state of
tea
:First overview of
login
:List of PR via 'pr ls':
Current state in Git:
Now I'm trying to checkout the PR#7:
I'm not sure if this related to the fact that the remotes in my repository look like this:
Furthermore I've observed that I can't set the URL:
Maybe I mistaken here a thing (I'm not sure if this related).
This is a duplicate of #253.
Though I'll close the other one as you provided a better bug description ;)
I guess the bug boils down to tea selecting the wrong auth method/key in
git.GetAuthForURL()
.On my machine the command works fine, so could you provide some details on your SSH setup?
~/.ssh/id_rsa
?ssh_key
for thekh.marbaise
login in your tea config?~/.ssh/config
for theIP:Port
host?This is as expected; the
-u --url
param should include just the hostname of the gitea instance¸possibly prefixed withhttps://
.No it's exactly the same.
Yes
/usr/bin/ssh-agent -l
(MacOS).No I did not see my
tea.yml
:Nothing defined for that IP:Port combination...
@khmarbaise Thank you! Looks like a standard setup, so this should certainly work.
I'll try to reproduce on my side
@khmarbaise Could you build tea from #277 and try if you still have this issue?
Please test once with your existing configuration, and then once after re-adding the login to your tea config (
tea login edit
,tea login add
)First no change in my configuration etc. also
login ls
as describe above.So using:
Building via:
The Git state:
Now the list of PR available:
So trying to change onto branch
ISSUE-277-1
via:No errors so far but there has been created a branch (which not needed because there does already exist one
ISSUE-277-1
). This could make sense if I try to get a PR from someone else.and really astonishing is the following:
Added a supplemental remote with a different transport protocol (http instead of ssh based on the information from
login ls
maybe this could/should be controled different? ) for a PR which is coming from a different repository it makes sense...The question is if it would be possible to give some options to prevent generation of new branch and supplemental remote...(maybe special case and should be discussed in a different issue).
@khmarbaise thanks for testing.
With the changes in my branch, tea will always use https remotes, unless a ssh key has been configured for the login (which now happens automatically during
tea login add
, or manually by filling in a path inssh_key
intea.yml
).So that explains why it is https.
If the branch is already present in the local repo, no new branch or remote should be added (we search for a branch whose PR URL & remote URL point to the same repo).
This check fails however, when you have a ssh remote with explicit port specified, as tea has no way to tell which ssh and http
host:port
tuples point to the same gitea instance. I'm not sure if we can do anything about that.This problem should not be present, when you configure tea with your ssh key as described above; then the existing branch & ssh remote should be reused.
@khmarbaise I finally could reproduce the issue by starting a fresh instance of ssh-agent without any keys added. Can you verify that ssh-agent actually holds your key via
ssh-add -l
?If it's not listed there, your ssh setup is broken (-> either ssh-agent shouldn't be running or it should list your key).
edit:
If a broken setup like this is common (it seems so looking at repeated bug reports), tea should handle this gracefully, falling back to file-based publickey auth.
It turns out that this is rather tricky to implement with
go-git
/golang.org/x/crypto/ssh
: golang's ssh lib does not support providing two different publickey auth methods (i.e. ssh-agent based & file system based), because it tries to be smart and skips methods of the same type if the type was already tried.I patched that function, so now we have a working fallback. Question is, do we really want to maintain a local patch to
x/crypto/ssh
? You can take a look at the patches here..@khmarbaise can you recheck current master if the issue still exist?
@noerw Can you explain in which way the ssh setup is broken ? and I've rechecked ssh-agent and it does not hold any key:
So checking against
tea
master (f5b0004a52
)So the list of git branches and my current location:
Furthermore the list of PR's which are avaialable on Gitea:
So now I try to get PR with index 11 (branch: CHANGE 1)
I've realized one change in the
~/.tea/tea.yml
file:The
ssh_key
has been set which hasn't been before.Also check as suggested to use:
@khmarbaise If you have the environment variable
SSH_AUTH_SOCK
set, SSH clients are inclined to use the SSH agent listening at that socket for key management. tea is no exception, and tries to authenticate using that ssh-agent.This fails in your case, as your ssh-agent has no keys registered in it. I'm not sure how that happens; scripts that start ssh-agent and export
SSH_AUTH_SOCK
usually also take care of populating the agent with keys (eg. from~/.ssh
dir).The solution is to either stop ssh-agent from running, or to have it hold your keys.
I'm closing this issue, as this is not a tea bug. If this problem comes up more often, we can consider making tea handle this case with a fallback as outlined in this comment, but thats tricky.