Git internals don't work remote oauth url

[mrbrownt]

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.

[zaquestion]

@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:

lab/cmd/mr_create.go

Lines 178 to 183 in a7646da

	func determineSourceRemote(branch string) string {
	// Check if the branch is being tracked
	r, err := gitconfig.Local("branch." + branch + ".remote")
	if err == nil {
	return r
	}

is the only way I could see it possible for

lab/cmd/mr_create.go

Lines 80 to 84 in a7646da

	sourceRemote := determineSourceRemote(branch)
	sourceProjectName, err := git.PathWithNameSpace(sourceRemote)
	if err != nil {
	log.Fatal(err)
	}

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]

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.

[mrbrownt]

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 = git@gitlab.com: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

[bmeneg]

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]

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.