GitLab CI/CD流水线阶段依赖与可执行文件路径问题咨询

我来帮你搞定这个CI/CD流水线的问题～你遇到的核心卡点其实很明确：GitLab CI的工件系统只认项目目录（$CI_PROJECT_DIR）下的文件，/usr/local/bin属于容器的系统路径，根本没法被自动传递到测试阶段。下面给你几个不用放弃make install的优雅方案，按需选就行：

方案一：自定义安装路径到项目目录（最推荐） #

这是最贴合标准构建流程的做法——咱们不用改Makefile，只需要在执行make install时指定DESTDIR参数，把安装产物放到项目目录下的子文件夹里，再把这个文件夹设为工件传递给测试阶段。

修改后的.gitlab-ci.yml示例：

image: gcc
stages:
  - build
  - test
build_app:
  stage: build
  script:
    - make
    # 把安装路径指向项目目录下的install子文件夹
    - make install DESTDIR=$CI_PROJECT_DIR/install
  artifacts:
    paths:
      - install/
test_app:
  stage: test
  dependencies:
    - build_app
  script:
    # 从传递过来的工件目录里调用安装好的程序
    - ./install/usr/local/bin/app ...

这个方案的好处：既保留了make install的常规流程，又让工件路径完全符合GitLab的要求，测试阶段调用的是和生产环境一致的安装后文件，更能模拟真实运行场景。

方案二：复制二进制文件到项目目录（最简操作） #

如果不想调整安装路径，也可以在构建阶段最后加一步，把/usr/local/bin里的二进制文件复制到项目目录下，再把它设为工件。

示例配置：

image: gcc
stages:
  - build
  - test
build_app:
  stage: build
  script:
    - make
    - make install
    # 把编译好的二进制复制到项目目录
    - cp /usr/local/bin/app $CI_PROJECT_DIR/
  artifacts:
    paths:
      - app
test_app:
  stage: test
  dependencies:
    - build_app
  script:
    - ./app ...

这个方案操作最简单，不用改构建逻辑，只是多了一步复制，适合快速解决问题的场景。

方案三：用缓存？别踩坑！ #

可能有人会想到用GitLab的缓存来传递文件，但非常不推荐——缓存的设计目的是加速重复构建（比如缓存依赖包），不是用来传递阶段产物的，很容易出现并发流水线的缓存冲突，导致测试阶段拿到错误的文件，稳定性完全没法保证。

总的来说，方案一是最优选择，既符合规范又能保证测试的真实性；如果追求快速上手，方案二也完全够用。

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