[Feature flag] Enable Git 2.38
What
Enable the :git_v238
feature flag. This will cause git operations to use git v2.38.1.
Owners
- Team: Gitaly
- Most appropriate slack channel to reach out to:
#g_gitaly
- Best individual to reach out to: NAME
Expectations
What release does this feature occur in first?
15.6
What are we expecting to happen?
All RPCs should continue operating as normal
What might happen if this goes wrong?
Git operations will start failing.
Here is a list of the improvements/changes in the git 2.38 minor release that might affect existing Gitaly functionality (the full list is here)
None of these changes should pose an immediate risk to Gitaly
UI related:
- When "git merge" finds that it cannot perform a merge, it should restore the working tree to the state before the command was initiated, but in some corner cases it didn't.
- Various messages that come from the pack-bitmap codepaths have been tweaked.
Performance, Internal Implementation, etc
- Collection of what is referenced by objects in promisor packs have been optimized to inspect these objects in the in-pack order.
- Teach "git archive" to (optionally and then by default) avoid spawning an external "gzip" process when creating ".tar.gz" (and ".tgz") archives.
- Allow large objects read from a packstream to be streamed into a loose object file straight, without having to keep it in-core as a whole.
- The pack bitmap file gained a bitmap-lookup table to speed up locating the necessary bitmap for a given commit.
Fixes:
- Plug various memory leaks, both in the main code and in test-tool commands.
- "git clone" from a repository with some ref whose HEAD is unborn did not set the HEAD in the resulting repository correctly, which has been corrected.
- "git fsck" reads mode from tree objects but canonicalizes the mode before passing it to the logic to check object sanity, which has hid broken tree objects from the checking logic. This has been corrected, but to help existing projects with broken tree objects that they cannot fix retroactively, the severity of anomalies this code detects has been demoted to "info" for now.
- An earlier optimization discarded a tree-object buffer that is still in use, which has been corrected.
- Fix deadlocks between main Git process and subprocess spawned via the pipe_command() API, that can kill "git add -p" that was reimplemented in C recently.
- The clean-up of temporary files created via mks_tempfile_dt() was racy and attempted to unlink() the leading directory when signals are involved, which has been corrected. (merge babe2e0559 rs/tempfile-cleanup-race-fix later to maint).
- A result from opendir() was leaking in the commit-graph expiration codepath, which has been plugged. (merge 12f1ae5324 ml/commit-graph-expire-dir-leak-fix later to maint).
What can we monitor to detect problems with this?
https://dashboards.gitlab.net/d/gitaly-main/gitaly-overview?orgId=1
Roll Out Steps
-
Enable on staging -
Is the required code deployed on staging? (howto) -
Enable on staging (howto) -
Add featureflagstaging to this issue (howto) -
Test on staging (howto) -
Verify the feature flag was used by checking Prometheus metric gitaly_feature_flag_checks_total
-
-
Enable on production -
Is the required code deployed on production? (howto) -
Enable on production in #production
(howto) -
Add featureflagproduction to this issue -
Verify the feature flag was used by checking Prometheus metric gitaly_feature_flag_checks_total
-
-
Default-enable the feature flag (optional, only required if backwards-compatibility concerns exist) -
Wait for release containg default-disabled feature flag. -
Change the feature flag to default-enabled (howto) -
Wait for release containing default-enabled feature flag.
-
-
Remove feature flag -
Remove old Git version from build
Please refer to the documentation of feature flags for further information.
Edited by Toon Claes