FS#74948 - [gitlab-gitaly] should use custom git binary instead of system git

Attached to Project: Community Packages
Opened by Joshua Holmer (Soichiro) - Friday, 03 June 2022, 02:23 GMT
Last edited by Caleb Maclennan (alerque) - Wednesday, 24 May 2023, 20:14 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Anatol Pomozov (anatolik)
Caleb Maclennan (alerque)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

It is recommended to use the custom git binary which is included with gitaly, according to https://docs.gitlab.com/ee/install/installation.html#git.
Using the system git can cause issues such as this one: https://gitlab.com/gitlab-org/gitlab/-/issues/360783


Additional info:
* package version(s): All
* config and/or log files etc.: N/A
* link to upstream bug report, if any: See description
This task depends upon

Closed by  Caleb Maclennan (alerque)
Wednesday, 24 May 2023, 20:14 GMT
Reason for closing:  Won't implement
Comment by Caleb Maclennan (alerque) - Wednesday, 24 May 2023, 20:13 GMT
I think I'm going to close this a "won't fix". I know what upstream recommends, but they also recommend you run their omnibus container, not bare metal source builds like Arch packages. In general we try *not* to use vendored stuff where possible, and the Git binary is a pretty good candidate for using the system one not some vendored one.

The specific issue linked above was a bug in Gitlab/Gitaly and subsequently fixed. Looking forward with Gitaly 16 they are dropping Ruby and the mix-and-match with Rugged wrapper on libgit2 plus Git system calls in favor of Go and *only* Git system calls. We'll see how packaging that goes, but the initial goal for Arch will be to use the system Git unless we really need to let it be vendored.

Feel free to open bugs if you have ongoing issues with this approach.

Loading...