GitLab CI中.gitmodules拉取子仓库失败致Maven找不到pom.xml

看起来你遇到的核心问题是Git子模块的克隆路径和你的CI任务预期不一致，导致Maven无法找到指定的pom.xml文件。我们一步步来拆解和修复：

问题根源分析 #

1. 你的.gitmodules配置里，path = logging-service指定了子模块会被克隆到当前仓库（bothub-deployment-dev）的根目录下，也就是路径/builds/ole_bothub/bothub-deployment-dev/logging-service——这其实是Git子模块的默认行为。
2. 但你的部分CI任务（比如test_coverage_phase_logging-service）错误地使用了../logging-service/pom.xml，期望子模块在当前仓库的父目录（/builds/ole_bothub/logging-service），这和实际克隆路径不符，直接导致了找不到文件的错误。
3. 另外，你的SonarQube任务的Maven命令格式有误，也会加重路径问题。

具体修复步骤 #

1. 修正CI任务中的路径引用 #

把所有CI任务里的pom.xml路径调整为子模块实际的克隆路径：

• 对于test_coverage_phase_logging-service，把脚本改为：

  mvn clean verify -f logging-service/pom.xml
  

• 对于sonar_qube_phase_logging-service，修正Maven命令的参数顺序（sonar:sonar应该是目标，放在-f参数之前）：

  mvn sonar:sonar -f logging-service/pom.xml -Dsonar.host.url=$SONAR_URL -Dsonar.login=$SONAR_USERNAME -Dsonar.password=$SONAR_PASSWORD
  

2. 验证子模块是否被正确克隆 #

可以在maven_build_phase_logging-service的脚本开头加一步验证，确认子模块文件存在：

# 检查子模块目录和pom.xml是否存在
ls -la logging-service/

如果输出里能看到pom.xml，说明子模块克隆正常；如果看不到，可能需要检查GitLab的子模块权限（确保当前CI Runner有权限访问logging-service仓库）。

3. 确认GitLab CI子模块策略生效 #

你已经设置了GIT_SUBMODULE_STRATEGY: recursive，这是正确的配置，它会自动递归克隆所有子模块。如果还是有问题，可以尝试在CI变量里添加GIT_SUBMODULE_FORCE_HTTPS: true（如果你的子模块用的是SSH URL，CI Runner可能没有对应的密钥）。

（可选）如果确实需要子模块在父目录（不推荐） #

如果你的业务逻辑必须让子模块和当前仓库同级，那可以放弃Git子模块的自动克隆，手动在CI脚本里克隆子模块：
在CI的before_script里添加：

# 切换到父目录克隆子模块
cd ..
git clone ../logging-service.git
# 切回当前仓库目录继续执行任务
cd bothub-deployment-dev

但这种方式会脱离Git子模块的版本管理，后续维护成本更高，优先推荐前面的路径修正方案。

内容的提问来源于stack exchange，提问作者fathy elshemy