我不太确定gitlab CI工作流程应该如何实现:

  • 在我的gitlab资源库中,每个功能都将在自己的分支中开发 . 至少该分支将合并为master .

  • 我正在使用npm package grunt-bump来提升package.json的版本

我想用gitlab CI做什么:

  • 对于 merge to master 我想做一些测试(阶段测试)

  • 如果测试阶段已成功通过,则应完成合并并执行 grunt bump

  • 这将提升版本值,并将执行新的提交以掌握 . 此提交始终标记为"v0.0.2",并且具有类似"Release v0.0.2"的消息 . 只有这个提交,我想去构建阶段,它将构建和部署应用程序 .

Summary

所以 grunt bump 只应在master上和成功测试和合并后执行 . 仅对于生成的提交(Release vx.x.x),应该完成构建和部署作业...

也许这个想法有一个更聪明的工作流程 . 基本上我想在合并和成功测试后提高版本值并标记提交...

My attempt for YAML-file

stages:
  - test
  - build
  - deploy

lint:
  image: testing:latest
  stage: test
  tags:
    - testing
  script:
    - /node_modules/.bin/eslint --ext .js --ext .jsx .

bump:
  stage: build
  tags: 
    - deploy
  script:
    - grunt bump
  only:
    - master
    - /^Merge .*$/

build:
  stage: build
  tags:
    - deploy
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:latest
  only:
    - master
    - tags
    - /^Release .*$/

production:
  stage: deploy
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:latest
    - cd /home/ubuntu
    - docker-compose up -d
  only:
    - master
    - tags
    - /^Release .*$/