基于访问令牌不一致行为的git子模块更新

Question

上下文

在一个具有多个用户和组的自管理GitLab实例上，我试图在.gitlab-ci.yml of main_project中执行一个git submodule update --init --recursive。这个回购包含一个子模块(filter_lib)，它本身包含一个子模块(helper_funcs)：

main_project
├── app
│   └── filter_lib                    <- submodule
│       ├── .gitmodules
│       ├── lib
│       └── helper_funcs              <- submodule
│           └── funcs
├── .gitmodules
├── .gitlab-ci.yml
├── .gi
└── tests
    └── test_stuff.py

main_project属于一个GitLab组(我们称之为group1)，两个子模块(filter_lib和helper_funcs)都属于另一个GitLab组和子组(group2/subgroupA)，没有访问权限：

my_gitlab_instance
├── group1
│   └── main_project
└── group2
    └── subgroupA
        ├── filter_lib
        └── helper_funcs

问题

我想init所有的子模块。

首先，在我的.gitlab-ci.yml开始时，我尝试使用这段代码

variables:
  GIT_SUBMODULE_STRATEGY: recursive

在尝试运行我的脚本之前，此CI失败了，出现了以下错误：

Updating/initializing submodules recursively with git depth set to 50...
Submodule 'app/filter_lib' (https://gitlab-ci-token:[MASKED]@my_gitlab_instance.com/group2/subgroupA/filter_lib.git) registered for path 'app/filter_lib'
Cloning into '/builds/group1/main_project/app/filter_lib'...
Submodule path 'app/filter_lib': checked out '28d6c0f2d0bc691c29a406f44ae9b69b4e00f2b2'
Submodule 'helper_funcs' (git@gitlab:group2/subgroupA/helper_funcs) registered for path 'app/filter_lib/helper_funcs'
Cloning into '/builds/group1/main_project/app/filter_lib/helper_funcs'...
error: cannot run ssh: No such file or directory
fatal: unable to fork
fatal: clone of 'git@gitlab:group2/subgroupA/helper_funcs' into submodule path '/builds/group1/main_project/app/filter_lib/helper_funcs' failed
Failed to clone 'helper_funcs'. Retry scheduled
Cloning into '/builds/group1/main_project/app/filter_lib/helper_funcs'...
error: cannot run ssh: No such file or directory
fatal: unable to fork
fatal: clone of 'git@gitlab:group2/subgroupA/helper_funcs' into submodule path '/builds/group1/main_project/app/filter_lib/helper_funcs' failed
Failed to clone 'helper_funcs' a second time, aborting
Failed to recurse into submodule path 'app/filter_lib'

这在某种程度上是预料中的，因为group1/main_project在group2中没有任何回购的读取权限。

因此，我尝试了另一种方法，通过将GIT_SUBMODULE_STRATEGY更改为normal，并允许group1/main_project以下列方式访问group2/subgroupA/filter_lib和group2/subgroupA/helper_funcs：

对于filter_lib，我进入了repo > Access，生成了一个带有所有可用范围和Maintainer角色的令牌。然后，我在main_project > Settings > CI/CD >变量中添加了这个令牌，作为一个名为FILTER_LIB_CLONE_KEY的蒙面变量。对于helper_funcs，我也是这样做的，变量名为HELPER_FUNCS_CLONE_KEY。

请注意，以下所有命令都是通过.gitlab-ci.yml of main_project**.**执行的

然后，在尝试使用.gitmodules of main_project之前，我对git submodule update进行了研究，使其在CI阶段如下所示：

$ cat .gitmodules
[submodule "app/filter_lib"]
    path = app/filter_lib
    url = https://gitlab-ci-token:[MASKED(FILTER_LIB_CLONE_KEY)]@my_gitlab_instance.com/group2/subgroupA/filter_lib.git

在git submodule update --init中运行main_project成功克隆了group2/subgroupA/filter_lib的内容

$ cd app/filter_lib
$ ls -al
total 23
drwxrwxrwx    4 root     root          4096 May 17 10:51 .
drwxrwxrwx    3 root     root          4096 May 17 09:24 ..
-rw-rw-rw-    1 root     root            40 May 17 09:24 .git
-rw-rw-rw-    1 root     root           137 May 17 10:51 .gitmodules
drwxrwxrwx    2 root     root          4096 May 17 10:52 helper_funcs
drwxrwxrwx    6 root     root          4096 May 17 09:24 lib

我对app/filter_lib/.gitmodules也做了同样的操作，在sed之后的CI期间，它看起来是这样的：

$ cat app/filter_lib/.gitmodules
[submodule "helper_funcs"]
    path = helper_funcs
    url = https://gitlab-ci-token:[MASKED(HELPER_FUNCS_CLONE_KEY)]@my_gitlab_instance.com/group2/subgroupA/helper_funcs.git
    ignore = dirty

在filter_lib中，我做了：

$ git submodule update
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@gitlab:group2/subgroupA/helper_funcs' into submodule path '/builds/group1/main_project/app/filter_lib/helper_funcs' failed
Failed to clone 'helper_funcs'. Retry scheduled
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@gitlab:group2/subgroupA/helper_funcs' into submodule path '/builds/group1/main_project/app/filter_lib/helper_funcs' failed
Failed to clone 'helper_funcs' a second time, aborting

然而，手动克隆helper_funcs回购在正确的地方与HELPER_FUNCS_CLONE_KEY工作。

为什么git clone是可能的，而git submodule update却不能使用相同的回购url呢？

为什么git submodule update在第一个子模块上工作，而不是在第二个子模块上工作，即使访问权限是相同的？

Answer 1

正如@torek在注释中所述，git仍然通过ssh使用身份验证，而不是按需要使用https。

我也有同样的问题。在我的例子中，我在工作中安装了openssh。不安装openssh是git开始使用https的方式。

更确切地说，我的安装命令来自：

    - apk add gcc linux-headers musl-dev git openssh

至

    - apk add gcc linux-headers musl-dev git

不过，我不知道为什么在安装openssh时，git使用ssh方法而不是https方法。