Improve git worktree handling when creating SDK containers #1351
Conversation
The library has the following functionality: - Discover the git repository layout. This figures out where is the main repository (whose `.git` entry is a directory and contains all the git configuration and objects) and all its linked worktrees (their `.git` entries are just files with a path to their respective worktree metadata directory inside the main repo's `.git`). The layout is basically two things: a path to the main repo and a map of linked worktree name to the path of the linked worktree. Name of a worktree is the `<name>` part in the path `<main-repo>/.git/worktrees/<name>`. - Map the discovered git repository layout into possible git repository layout inside the SDK container. The worktrees (both main one and linked ones) are put into a chosen base directory inside SDK so the main worktree is in `<base>/main-repo`, while linked worktrees are in `<base>/linked/<name>`. It's also possible to override the path for any worktree to be put elsewhere (for example, we may want to put the worktree being in current working directory to `/mnt/host/source/src/scripts`, while the rest of the worktrees go somewhere under `/mnt/host/all-worktrees/scripts` directory). - Generate Docker volume options based on both git repository layouts. It results in an array of strings in form of `"-v" "<path-to-worktree:path-to-worktree-inside-SDK"` that can be passed directly to docker/podman. - Generate replacements based on git repository layout inside the SDK container. Replacements is a bash file to be sourced. It defines a map of file paths to the new contents that those files should have. Currently the generated replacements are for `.git` files in the linked worktrees and `gitdir` files inside main worktree's `.git/worktrees/<name>` directories. Such replacement file should be mounted inside the SDK container with -v option (just like the worktrees). - Map the replacements to a set of bind-mounts. This action should be done inside the SDK container - it sources the replacements files, creates temporary files with the contents being the values in the map from the replacements file and bind-mounts them into the locations being keys of the map.
This is something I have done, because I needed it in early drafts of the work. The work has evolved and the need disappeared, but maybe it makes sense to keep it.
This makes sure that the worktrees mounted into the SDK container properly reference other worktrees, so they won't be treated by git as stale and get cleaned up.
Nothing changes if the scripts repo is standalone and has no linked worktrees.
They get the same treatment like the scripts repo.
Test report for 3780.0.0+nightly-20231106-2100 / amd64 arm64Platforms tested : qemu_uefi-amd64 qemu_update-amd64 qemu_uefi-arm64 qemu_update-arm64
Diagnostic output for qemu_uefi-arm64, run 1
Diagnostic output for qemu_uefi-arm64, run 1
Diagnostic output for qemu_uefi-amd64, run 1
Diagnostic output for qemu_update-arm64, run 1
Diagnostic output for qemu_uefi-amd64, run 1
Diagnostic output for qemu_uefi-arm64, run 2Diagnostic output for qemu_uefi-arm64, run 1
Diagnostic output for qemu_uefi-arm64, run 1
|
This mounts all related worktrees of the scripts repo and of any extra git repo passed through the -g option into the SDK container, so:
For more details, please see the commit messages, especially the one that adds the git worktree handling library.
Tested locally.