lab icon indicating copy to clipboard operation
lab copied to clipboard

Git internals don't work remote oauth url

Open mrbrownt opened this issue 5 years ago • 5 comments

I am using an oauth remote url in the format https://oauth2:${SERVICE_ACCOUNT_GITLAB_TOKEN}@gitlab.com/${CI_PROJECT_PATH}.git

When running lab mr create ${BRANCH} master I'm getting the following error.

mr_create.go:83: the key `remote.https://oauth2:[MASKED]@gitlab.com/some/repo.git.url` is not found

I know this upstream remote url does exist because it's was used to create a branch prior to this command. I'm running this all in gitlab CI.

mrbrownt avatar Jun 29 '20 22:06 mrbrownt

@mrbrownt Can you share the git config for this and verify what version of lab you're running? It's very weird that we'd return the error like that. The lookup in play is trying to determine the project path from the remote url.

Is ${BRANCH} in this case referring to: https://oauth2:${SERVICE_ACCOUNT_GITLAB_TOKEN}@gitlab.com/${CI_PROJECT_PATH}.git ?

Just to be clear, the create usage is as below, and refers to the name of the remote in your git config.

create [remote [branch]]

That said you don't seem to be making it far enough for the arguments you're providing to actually come into play. Based on the error output, my guess is there is some git config that looks like

[branch "mybranch"]
	remote = https://oauth2:${SERVICE_ACCOUNT_GITLAB_TOKEN}@gitlab.com/${CI_PROJECT_PATH}.git
	merge = refs/heads/mybranch

As this logic: https://github.com/zaquestion/lab/blob/a7646da14338df8cdaabc2a9f80c45d47c2bd322/cmd/mr_create.go#L178-L183 is the only way I could see it possible for https://github.com/zaquestion/lab/blob/a7646da14338df8cdaabc2a9f80c45d47c2bd322/cmd/mr_create.go#L80-L84 to fail with the error you're seeing.

I would have thought the above git config would be invalid, so if that's not the case and remote can be equal to a url, then that would be the bug we need to address in lab and we'd need to be a bit surgical to support it everywhere it needs to be. A workaround would probably be to add the remote definition in a way lab expects

[remote "oauthurl"]
	url = https://oauth2:${SERVICE_ACCOUNT_GITLAB_TOKEN}@gitlab.com/${CI_PROJECT_PATH}.git
	fetch = +refs/heads/*:refs/remotes/oauthurl/*
[branch "mybranch"]
	remote = oauthurl
	merge = refs/heads/mybranch

zaquestion avatar Sep 18 '20 00:09 zaquestion

The git docs don't make this any clearer: https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtremote

But I did try this out locally and evidently you can set branch.<name>.remote directly to the remote url TIL

Changes to both determineSourceRemote and git.PathWithNameSpace will need to be made to support this.

zaquestion avatar Sep 18 '20 00:09 zaquestion

The workflow involved was on gitlab-ci, so it was a fresh clone. The script I was running checked out a branch, added a commit and then directly pushed to origin with:

git push --set-upstream https://oauth2:${PAT_TOKEN}@gitlab.com/${CI_PROJECT_PATH}.git

The main reason for doing said workflow is that ci tokens don't have push access so I'm using a personal access token, thus the magic of --set-upstream.

Doing this locally produced this config, which looks to match your research there.

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = [email protected]:some/repo.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "test"]
        remote = https://oauth2:${PAT_TOKEN}@gitlab.com/some/repo.git
        merge = refs/heads/test

mrbrownt avatar Oct 02 '20 05:10 mrbrownt

That's new to me too! Interesting finding... I'm going to dig on that and try to come up with a fix. Thanks for the report @mrbrownt and for referencing it in the #457 PR @zaquestion .

bmeneg avatar Oct 06 '20 00:10 bmeneg

Ok, after some time I came back to this and just now I realized that an URL can only be used as remote for git push, while I can't add an actual remote with this name. It eases our lives a bit, since we don't need to worry about an URL being passed as one of the commands CLI arguments.

bmeneg avatar Feb 11 '22 19:02 bmeneg