Gitlab跨仓库引用CI配置时wget未执行导致文件复制失败如何解决

核心原因 #

出现wget步骤未执行的情况，本质是GitLab CI多仓库配置合并时的覆盖规则导致，常见原因如下：

• Repo B的CI配置中存在同名Trivy_container_scanning作业，自定义了before_script字段，GitLab CI默认会使用Repo B的配置直接替换Repo A中对应作业的before_script，导致原本定义的wget步骤完全丢失。
• 如果Repo A中的wget步骤是定义在全局before_script而非Trivy_container_scanning作业内部的，只要Repo B自身也定义了全局before_script，就会完全覆盖Repo A的全局配置，作业执行时不会触发wget步骤。
• 少部分情况为Repo B对该作业使用extends、!reference等扩展语法时逻辑错误，导致原有步骤被覆盖。

修复方案 #

• 若Repo B不需要修改该扫描作业的原有逻辑，直接删除Repo B中同名的Trivy_container_scanning作业配置，完全复用Repo A中定义的作业即可。
• 若Repo B需要在该作业中新增自定义步骤，不要直接重写before_script，通过!reference引用Repo A的原有步骤后再追加新步骤，示例配置如下：

Trivy_container_scanning:
  before_script:
    - !reference [Trivy_container_scanning, before_script]
    - 新增的自定义执行命令

• 若Repo A的wget步骤定义在全局before_script中，将这部分逻辑迁移到Trivy_container_scanning作业内部的before_script字段下，避免被Repo B的全局配置覆盖。
• 可以在该作业的before_script开头添加set -x开启命令打印，同时在wget命令末尾添加|| exit 1，确保wget执行失败时直接终止作业，避免后续cp步骤报错，也方便排查执行日志。
• 确认Repo B绑定的Runner没有配置全局before_script覆盖规则，也没有禁用wget命令，同时确认Repo B的CI_TOKEN已经获得Nexus仓库的访问权限，避免因权限问题导致wget静默失败。

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