Skip to content

Install ssh client in helper container (either always or when GIT_SUBMODULE_STRATEGY is not "none")

Feature disposition status (2022-12-22)

We do not plan to implement this feature in the helper container.

The helper image is used everywhere and is created/deleted multiple times during a build. If we add more software to the helper image, it will just get slower and harder to maintain.

Therefore our guiding principle is to keep the helper image as lightweight as possible.

GIT_SUBMODULE_STRATEGY doesn't work with SSH submodules

As explained in #2075 (closed), the helper image used to clone the repository doesn't contain a SSH client, so GIT_SUBMODULE_STRATEGY=recursive or GIT_SUBMODULE_STRATEGY=normal fail when a submodule uses SSH. This is also mentioned in the documentation: Git submodule strategy

This behavior is surprising, and I think when setting GIT_SUBMODULE_STRATEGY, it is fair to assume that cloning SSH submodules would work. Cloning over SSH is a central git feature, it should also be supported for submodules in Gitlab CI.

Paths for submodule URLs have the disadvantage that they require the exact same folder structure on every developers machine.

HTTPS has the disadvantage that you either have to enter the credentials every time or store them, which both has security implications.

Furthermore, with recursive submodules it might not even be under your control.

Proposal

Either just always install SSH client into the helper image or install it when GIT_SUBMODULE_STRATEGY is set to normal or recursive.

I think always installing SSH client should be OK from a security point of view. But it would either require a customized helper image or an installation step for every pipeline. So it would probably be better to just install a SSH client when GIT_SUBMODULE_STRATEGY is set to normal or recursive.

Edited by Darren Eastman