0

I have a git repository containing several submodules, and a gitlab runner (project specific) registered to a virtual machine. The CI/CD uses a makefile which is contained within one of the submodules.

Previously I have been able to clone the repository and all of the submodules on both my local machine and the virtual machine with no problems, and also the CI/CD worked (but failed on something in the makefile - unrelated)

This week when I have come back to this project to fix the problem with the makefile, I am now getting two problems with the virtual machine and gitlab runner.

Problem 1: git is now asking for my username and password for each submodule when cloning the submodules on the virtual machine (git submodule update --remote). I am not getting the same problem with my local machine, that is cloning without the need for a username and password.

Strangely, the gitlab-runner is also asking for a username and password when I run the pipeline.

I can store my username and password so the virtual machine doesn't ask for it, but this doesn't help with the runner.

Problem 2: when trying to clone the submodules - git submodule update --remote, I get the message: fatal: Needed a single revision Unable to find current origin/master revision in submodule path '[submodule]' I can fix this by adding branch = main into the .gitmodules file, but again this isn't necessary on my local machine, only the virtual machine (and only this week; it didn't previously need this).

What's going on here?

I have done a compare of the .git folders for the last working revision of my project and the current one, the differences were inconsequential (HEAD, where one is main, the other is the git hash).

I tried reverting to the last working revision, and had the same problems. This suggests to me it is a problem with my working environment rather than any git files.

clarky
  • 21
  • 4
  • If you are using an `https://` URL to clone, and the server (GitLab) requires a password, Git will run the configured credential helper to obtain user name and password. You'll have to either supply something (build-system username and build-system token perhaps) or use some other method to authenticate. – torek Dec 09 '22 at 01:15
  • Yes, I can get around it that way, but that doesn’t help for the runner which should not require credentials. Also my local machine does not require credentials (they are not stored). – clarky Dec 10 '22 at 07:17
  • Sure, but we can then conclude that your local machine must have *some* credential helper set up: find out what it is and whether you can use it on the GitLab CI runner. – torek Dec 10 '22 at 09:09
  • The runner shouldn't need credentials though, it should use the gitlab-runner user. I'm trying to figure out what has changed rather than a workaround - something is also causing it to look for origin/master on my virtual machine, rather than main as it used to (and as it does on my local machine) – clarky Dec 12 '22 at 08:48
  • It would be nice if the runner didn't need credentials. Clearly whatever mechanism GitLab uses to bypass credentials for the primary repository (probably, "cloning it before starting the runner") doesn't work for submodules, though. Perhaps there's a way to get it to work? – torek Dec 12 '22 at 08:49
  • But it used to work; up until a week ago it would clone the repository and the submodules and go on to run the makefile. So, something has changed for it to no longer work, and to suddenly start looking for origin/master at the remote instead of main. – clarky Dec 12 '22 at 09:00
  • I'd bet that there's a stored credential somewhere that has now expired. Git itself hasn't changed here, nor has your setup. It's possible that GitLab have changed *their* software, of course... – torek Dec 12 '22 at 11:01

1 Answers1

0

Solution found with thanks to @torek for prompts, and help from here and here

Changing the submodule url in .gitmodules to use the relative path has removed both errors.

[submodule "ProjectA"]
    path = ProjectA
    url = ../../Proj/ProjectA.git
[submodule "ProjectB"]
    path = ProjectB
    url = ../../Proj/ProjectB.git

Checking the file history, .gitmodules has always used the absolute url up to now, so I'm not sure why this has suddenly become a requirement, but according to the documentation this is the correct way to avoid the need for credentials when cloning submodules in gitlab CI/CD

clarky
  • 21
  • 4