Skip to content

gitaly: Migrate to inject Git configuration via `config.toml`

Patrick Steinhardt requested to merge pks-gitaly-stop-writing-gitconfig into master

What does this MR do?

Currently, there is a single gitlab['omnibus-gitconfig'] setting that controls the Git configuration across different components of the stack by writing either a system-level or global-level gitconfig file. This makes it hard to see which parts of the gitconfig are used by what part of the stack.

For Gitaly the story is a bit complicated: the gitconfig files are in fact read, but almost all of its values are ignored because Gitaly uses its own set of defaults which override them, which is really confusing for administrators. Gitaly has instead introduced a new configuration [[git.config]] that needs to be added to its config.toml file, and this configuration does indeed override Gitaly's default configuration. We do not currently expose this setting in Omnibus though. To lessen the confusion what's read and what isn't, Gitaly will start to ignore all gitconfig files with v16.0.

Prepare for this deprecation by migrating from writing gitconfig files to instead writing [[git.config]] sections. Given that other parts of the stack may still be reading the old gitconfig files we cannot just stop writing gitconfig files. Instead, this commit carves out Gitaly's own gitconfig so that it can be configured independently of the rest of the stack.

Due to backwards-compatibility reasons we need to migrate old settings that had been set in omnibus_gitconfig['system'] automatically to the new gitaly['gitconfig'] configuration until v16.0 has been released.

This migration is further complicated by a deprecation in Git v2.36.0 itself though: if the old core.fsyncObjectFiles configuration is set, then Git will print a user-visible warning every time it's executed. Unfortunately though, administrators were required to set this config in the past, and we thus advertised this configuration entry as part of the default configuration. So we must ensure that this old default key is not set in the new configuration: in fact, we don't want any of the previously set defaults to end up in the new configuration so that Gitaly is the single source of truth with regards to what the defaults are. So in the general case, gitaly['gitconfig'] should be empty.

To work around this issue we thus automatically migrate configuration in omnibus_gitconfig['system'], but strip out any of the previous default values. The end result is thus a configuration that only contains what the administrator has manually overridden.

Related issues

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

  • Merge Request Title, and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks
  • trigger-package has a green pipeline running against latest commit

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • Documentation created/updated
  • Tests added
  • Integration tests added to GitLab QA
  • Equivalent MR/issue for the GitLab Chart opened
Edited by Patrick Steinhardt

Merge request reports