Externalize git configuration

Hannes Hörlrequested to merge
hhoerl/externalize-git-config into main

What does this MR do?

Externalize git configuration

We push git configuration into an external config, so that we don't taint the build directory. This external config is "include.path"ed

  • in the main repo's config (via the template)
  • explicitly (-c include.path=...) on certain submodule operations, where the main repo's config isn't picked up

Notes regarding some interesting topics:

  • relative builds_dir is taken care of; this should just work with relative paths, even though in some places we need to ensure we pass in the absolute path to the externalized config
  • FF_GIT_URLS_WITHOUT_TOKENS keeps working as is
  • the build url helper has been refactored to return more useful data, which is not coupled to its later use.
  • configuration that previously lived in the main repo's config (via template) has been pushed to the externalized config

Why was this MR needed?

-

What's the best way to test this MR?

Run a job against

  • a private repo
  • with submodules, either private or mix public & private
  • with FF_GIT_URLS_WITHOUT_TOKENS disabled and enabled

and see that

  • pulling the repos works
  • the repo's git config holds any creds
  • with FF_GIT_URLS_WITHOUT_TOKENS _dis_abled the creds are only in the now externalized config (${BUILD_TEMP}/.gitlab-runner.cred.conf)
  • with FF_GIT_URLS_WITHOUT_TOKENS _en_abled the creds are not to be seen in the now externalized config (${BUILD_TEMP}/.gitlab-runner.cred.conf)

What are the relevant issue numbers?

Edited by Hannes Hörl

Merge request reports