如何通过GitLab在本地网络正确执行Docker Compose脚本？

一、GitLab Runner仍是核心可行方案 #

你提到的弃用issue针对的是Kubernetes executor的部分旧特性，和本地Runner的使用完全无关——GitLab Runner至今仍是GitLab CI实现本地硬件依赖任务的标准方案，完全适配你的场景。

1. 部署本地Runner #

• 在能直接访问本地硬件和网络的机器上安装GitLab Runner（对应系统版本可从GitLab官方渠道获取）
• 注册Runner时，根据需求选择executor：
  • 选shell executor：直接在本地机器执行命令，天然能访问本地硬件，配置最简单
  • 选docker executor：需配置Docker使用host网络（network_mode: host），让容器能访问本地硬件资源
• 注册过程中设置专属标签（比如local-hardware-test），方便CI任务精准指定该Runner

2. 编写CI配置文件（.gitlab-ci.yml） #

示例配置如下，实现定时触发、启动Compose容器、执行测试、清理环境的完整流程：

stages:
  - test

nightly-hardware-test:
  stage: test
  tags:
    - local-hardware-test  # 绑定本地Runner的标签
  only:
    - schedules  # 仅允许定时任务触发
  script:
    - docker-compose up -d --build  # 启动容器（可选--build更新镜像）
    - docker-compose exec -T your-service bash -c "run-hardware-tests.sh"  # 执行测试命令
  after_script:
    - docker-compose down --volumes --remove-orphans  # 强制清理所有容器、卷和残留进程
  artifacts:
    paths:
      - test-results/  # 上传测试结果到GitLab，方便查看
    when: always  # 无论成功失败都保留结果

3. 设置定时触发 #

在GitLab仓库的「CI/CD」→「Schedules」页面添加定时任务，设置夜间执行时间（比如每天凌晨2点），关联上述job即可自动触发测试。

二、优化实践建议 #

• 权限预配置：在Runner机器上提前配置硬件访问权限（比如给Docker用户组添加串口、USB权限），避免CI执行时出现权限错误
• 环境固化：将Docker、Docker Compose等依赖提前安装并版本锁定，避免每次CI任务重复安装消耗时间
• 失败告警：在GitLab的「Settings」→「Integrations」中配置邮件、Slack等告警方式，当测试失败时及时通知
• 资源监控：给Runner机器配置基础监控（比如CPU、内存使用率），避免硬件测试占用过多资源影响其他服务

三、替代调试方案（非自动触发场景） #

如果需要手动调试测试流程，可使用gitlab-runner exec命令在本地直接运行CI任务，比如：

gitlab-runner exec shell nightly-hardware-test

但该方式不支持定时自动触发，仅适合开发调试阶段使用。

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