Sorry, my tired brain did not translate the variable into a URL, I wrongly shared origin where I should have explained git remote and how URLs come into play first.
One way is to always specify the URL in the git clone/pull/push command. Another way is to configure so-called remotes and only use the names to resolve to the actual URL.
Within the scope of the .gitlab-ci.yml, remotes might not make sense being configured for the short-lived jobs. Also, there are CI/CD variables available avoiding the copy-paste problems. Another use case for multiple remotes is keeping a fork in sync with upstream, Refreshing a Fork - #2 by dnsmichi I’d suggest going forward with variables, and not remotes. I only shared this detail for better understanding.
The error you are seeing with
Committer identity unknown
*** Please tell me who you are.
means that the local git binary does not have configuration about the user.author and user.email fields in the .gitconfig (it is blank in a fresh git package installation inside the runner executor and/or container image). One way to overcome this problem is doing the setup manually in CI/CD, similar to how you can do it with Git CLI on your desktop client.
before_script:
- git config --global user.email "our@email.com"
- git config --global user.name "Gitlab Runner"
A more in-depth example is shared in Git push from inside a gitlab-runner - #3 by epicode in the before_script section but using SSH keys instead of HTTPS as a Git transport.
Different approach: Git submodules
I kept thinking about the initial request to merge different repository sources in CI/CD jobs.
One way to avoid the knowledge of Git repository URLs and extra configuration in CI/CD can be to use git submodules in your main repository where the CI/CD pipeline is triggered.
git submodule add $RootRepoURL/$Repo.git “$SubmoduleFolder”
This way, the submodules are available to everyone cloning the repository for their development environments too, which might be handy with running local tests, etc. too. They are also visible in the GitLab UI.
Git submodules inside the GitLab Runner can be initialized by cloning the repository recursively. This step is done by the runner itself, you do not need any Git CLI commands yourself. Using Git submodules with GitLab CI/CD | GitLab The only required change is to specify a global variable to define the recursive clone strategy.
variables:
GIT_SUBMODULE_STRATEGY: recursive
Updating git submodules
The submodule’s directory points to a specific Git commit, which “pins” the version to exactly the submodule’s repository git commit. If you need to update the submodule’s content to latest, you can navigate into the directory, do a git pull, navigate outside, and commit the change to the main repository. In my experience, we did that as developers when pushing new versions in MRs, allowing us to test new revisions carefully.
Steps as a developer on a local client:
git fetch
git checkout main
git checkout -b update-submodule-xy
cd “$SubmoduleFolder”
git pull
cd ..
git commit -m "Update submodule XY" “$SubmoduleFolder”
git push -u origin HEAD