Skip to content

gitaly: Unconditionally ignore the gitconfig

Patrick Steinhardt requested to merge pks-gitaly-remove-ignore-gitconfig-toggle into master 
gitaly: Unconditionally ignore the gitconfig

In 4bf3bf85 (gitaly: Reintroduce migration to [[git.config]] stanzas,
2022-07-13), we introduced a toggle telling Gitaly to ignore any
gitconfig files on the local disk. Git configuration should only have
one source of truth, and with this toggle enabled Gitaly only uses its
own default values and overrides must be provided by the administrator
through the new `[[git.config]]` stanzas.

Because the initial attempt had to be reverted, this feature was rolled
out to our production fleet gated behind an opt-in flag. We observed no
change in behavior during testing, so this toggle may now be removed and
local gitconfig files will be permanently ignored.

Removes the flag and gitaly now ignores the gitconfig unconditionally.

Closes https://gitlab.com/gitlab-org/gitaly/-/issues/4230

Changelog: changed

What does this MR do?

In 4bf3bf85 (gitaly: Reintroduce migration to [[git.config]] stanzas, 2022-07-13), we have started to conditionally ask Gitaly to ignore any gitconfig files that exist on-disk to arrive at a single source of truth for the Git configuration. Instead, Gitaly now only uses its own default values as well as any overrides provided by the administrator via the new [[git.config]] stanzas.

Because the same change had to be reverted once in the past, this time around we have been taking the safe route and used a toggle in Omnibus to opt-in to the new behaviour. We have since rolled out this change to our production fleet without any observed change in behaviour.

Remove the flag and start to ignore the gitconfig unconditionally.

Related issues

Closes gitaly#4230 (closed).

Rollout merge requests: staging, canary, production.

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 Robert Marshall

Merge request reports