GitLab Runner是执行CI/CD任务的代理,需先在Ubuntu服务器上安装。常用安装方式(以Ubuntu 22.04为例):
# 添加GitLab Runner官方GPG密钥和软件源
curl -L --output /etc/apt/trusted.gpg.d/gitlab.asc https://packages.gitlab.com/gitlab/gitlab-runner/gpgkey
echo "deb https://packages.gitlab.com/gitlab/gitlab-runner/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/gitlab-runner.list
# 更新包列表并安装GitLab Runner
sudo apt-get update
sudo apt-get install gitlab-runner -y
安装完成后,可通过gitlab-runner --version验证是否成功。
注册Runner以关联GitLab项目,需获取项目的Runner URL和Registration Token(在GitLab项目页面→Settings→CI/CD→Runners中查看)。
# 注册Runner(以Shell executor为例,适用于本地执行)
sudo gitlab-runner register \
  --url https://gitlab.com/ \  # 替换为你的GitLab实例URL
  --registration-token YOUR_TOKEN \  # 替换为项目中的Token
  --executor shell \  # 可选:docker、kubernetes等(根据需求选择)
  --description "Ubuntu GitLab Runner" \  # Runner描述
  --tag-list "ci,test" \  # Runner标签(用于匹配CI/CD配置中的tags)
  --run-untagged=false \  # 是否运行未打标签的Job
  --locked=false  # 是否锁定Runner仅用于特定项目
注册成功后,Runner会出现在GitLab项目的Runners列表中。
在项目根目录下创建.gitlab-ci.yml文件,定义CI/CD流程(核心是stages和jobs)。以下是一个自动化测试的示例配置:
# 定义CI/CD流程的阶段(按顺序执行)
stages:
  - build
  - test
  - deploy
# 构建阶段:编译项目(以Maven项目为例)
build_job:
  stage: build
  script:
    - echo "Installing dependencies..."
    - mvn clean install -DskipTests  # 跳过测试,加快构建速度
  artifacts:
    paths:
      - target/*.jar  # 保存构建产物(供后续阶段使用)
    expire_in: 1 hour  # 产物过期时间
# 测试阶段:运行单元测试(以JUnit为例)
test_job:
  stage: test
  script:
    - echo "Running unit tests..."
    - mvn test  # 执行测试,生成JUnit报告
  artifacts:
    reports:
      junit: target/surefire-reports/*.xml  # 将测试报告上传至GitLab(可在UI中查看)
# 部署阶段:仅当测试通过后部署到生产环境(可选)
deploy_job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - scp target/*.jar user@server:/opt/app/  # 示例:将构建产物复制到服务器
  only:
    - master  # 仅当master分支有推送时触发
  when: on_success  # 仅在前面所有Job成功时执行
关键说明:
stages:定义流程的阶段顺序(build→test→deploy),Job按阶段依次执行。artifacts:用于传递阶段间的文件(如构建产物),expire_in设置过期时间(避免占用过多存储)。reports:上传测试报告(如JUnit),GitLab会自动解析并在CI/CD界面显示测试结果。Runner会自动监听项目的CI/CD事件(如代码推送、合并请求),并根据.gitlab-ci.yml中的配置执行Job。
only和except关键字控制Job触发时机(如only: - master表示仅master分支推送时触发)。test_job,可查看Job的日志(包括测试输出)和测试报告(若配置了artifacts.reports.junit)。rules中配置了if: '$CI_PIPELINE_SOURCE == "merge_request_event"'(如检测到合并请求时触发测试),测试结果会直接显示在合并请求页面,方便代码审查。node_modules或~/.m2),减少重复下载:build_job:
  stage: build
  script:
    - mvn clean install
  cache:
    paths:
      - ~/.m2/repository/  # 缓存Maven依赖
test_job_unit:
  stage: test
  script:
    - mvn test -Dtest=*UnitTest  # 运行单元测试
test_job_integration:
  stage: test
  script:
    - mvn test -Dtest=*IntegrationTest  # 运行集成测试
test_job:
  stage: test
  image: openjdk:17-jdk  # 使用指定Docker镜像
  script:
    - mvn test
sonarqube_check:
  stage: test
  image: sonarsource/sonar-scanner-cli
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  script:
    - sonar-scanner -Dsonar.projectKey=my-project -Dsonar.sources=. -Dsonar.host.url=$SONARQUBE_URL -Dsonar.login=$SONARQUBE_TOKEN
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'  # 仅在合并请求时触发
通过以上步骤,即可在Ubuntu环境下使用GitLab实现自动化测试,覆盖从代码提交到测试报告的全流程,提升开发效率和代码质量。