我不太确定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 .*$/