GitLab CI/CD
GIT_DEPTH: 这个变量定义了在克隆仓库时的深度。"0"表示将克隆整个仓库的历史记录。如果设置为一个正整数，例如"1"，那么只会克隆最近的一次提交记录。这可以加快克隆速度，特别是在大型仓库中。然而，这可能会导致一些依赖于完整历史记录的操作无法正常工作。
GIT_STRATEGY: 这个变量定义了 CI/CD 系统在每次运行 job 时如何处理代码仓库。它有三个可选值：
clone: 每次 job 运行时，都会克隆仓库的新副本。这意味着每次运行都会得到一个干净的工作副本，但可能会增加运行时间，特别是在大型仓库中。fetch: 在第一次运行 job 时，系统会克隆仓库。然后，在后续运行中，它将只获取（fetch）最新的更改，而不是完全重新克隆。这可以加快运行速度，但可能会导致工作副本中的残留文件和状态。none: CI/CD 系统不会执行任何与 Git 仓库相关的操作。这意味着您需要在 job 脚本中手动处理代码的获取和更新。这可以在某些特殊情况下提供更多的控制和灵活性。在您提供的配置中，GIT_DEPTH 设置为 "0"，表示克隆整个仓库的历史记录。GIT_STRATEGY 设置为 none，表示 CI/CD 系统不会自动执行任何与仓库相关的操作，您需要在 job 脚本中手动处理这些操作。
如果在 GitLab CI/CD 配置中将 GIT_SUBMODULE_STRATEGY 设置为 recursive（或 normal，如果您不需要嵌套子模块），以便在整个项目中克隆子模块，可能会产生以下影响：
更长的克隆时间：克隆子模块会增加代码仓库的克隆时间，特别是在具有多个子模块和大型子模块的项目中。这可能会导致 CI/CD 流程的运行时间变长。
更多的磁盘空间：克隆子模块会占用更多的磁盘空间，因为它们会将额外的代码和资源添加到工作目录中。这可能会导致磁盘空间不足，特别是在资源有限的环境中。
依赖项完整性：通过克隆子模块，您可以确保项目中的所有依赖项都被正确获取。这将有助于避免构建、测试和部署过程中的潜在问题。
更复杂的管理：对子模块的更改需要额外的关注，因为它们可能会影响主项目。您可能需要定期更新子模块的引用以保持同步，或者在子模块发生更改时触发 CI/CD 流程。
总之，将 GIT_SUBMODULE_STRATEGY 设置为 recursive 或 normal 以在整个项目中克隆子模块会增加克隆时间和磁盘空间占用，但可以确保依赖项的完整性。此外，管理子模块可能会变得更加复杂。您需要权衡这些影响，并根据项目的需求和资源来决定是否为整个项目启用子模块克隆。