GitLab CI流水线加载外部.sh脚本执行异常求助

我来帮你梳理几个大概率能解决问题的方向，毕竟我也踩过类似的坑：

1. 先给脚本加上可执行权限 #

虽然用sh test.sh调用时不需要脚本本身有执行权限，但如果脚本里涉及到一些需要权限的操作，或者CI环境对文件权限有严格要求，就容易出问题。你可以：

• 要么在CI的script里先加一步：chmod +x test.sh
• 要么本地给脚本加权限后提交到仓库：chmod +x test.sh && git add test.sh && git commit -m "Add execute permission to test.sh"

2. 给脚本指定正确的Shell解释器 #

在test.sh的第一行加上对应的shebang，比如node:6镜像里默认用的是sh，就加：

#!/bin/sh

如果是bash环境就加#!/bin/bash，避免因为环境里默认Shell不一致导致脚本执行异常。

3. 确保脚本在正确的工作目录执行 #

CI的工作目录有时候和你本地测试的路径不一样，脚本里的相对路径可能找不到文件。你可以：

• 在CI的script里先切换到项目根目录再执行脚本：cd $CI_PROJECT_DIR && sh test.sh
• 或者在脚本开头加pwd命令，打印当前路径，确认是不是你期望的目录。

4. 让脚本继承CI的环境变量 #

直接写在script里的步骤会自动继承所有CI环境变量（比如MySQL的连接地址、CI_PROJECT_DIR等），但用sh test.sh执行时，脚本会在子Shell里运行，可能丢失一些变量。解决办法：

• 用source test.sh代替sh test.sh，这样脚本会在当前Shell环境下执行，完全继承所有环境变量
• 或者显式传递需要的变量，比如：MYSQL_HOST=$MYSQL_HOST MYSQL_PORT=$MYSQL_PORT sh test.sh

5. 开启调试模式排查问题 #

在test.sh的开头加上set -x，这样每一步执行的命令都会打印出来，你能清楚看到哪一步出错了——是权限不够、路径不对，还是命令本身有问题。另外也可以在CI的script里先加whoami和pwd，确认当前用户和工作目录是否符合预期。

6. 检查是否需要root权限 #

如果脚本里有安装系统包之类的操作，node镜像默认用户不是root，会有权限错误。这时候可以：

• 在CI配置里添加user: root，让job以root用户运行（不推荐，但临时调试好用）
• 或者在脚本里给需要权限的命令加上sudo（前提是镜像里安装了sudo）

修改后的CI配置示例 #

test:
  image: node:6
  services:
    - name: mysql:5.7
  stage: test
  script:
    - chmod +x test.sh
    - cd $CI_PROJECT_DIR
    - source test.sh  # 用source继承环境变量
  tags:
    - docker
  when: manual

脚本开头示例 #

#!/bin/sh
set -x  # 开启调试，方便排查

# 你的测试步骤
npm install
npm run test
# ...其他命令

内容的提问来源于stack exchange，提问作者eragon-2006