Gitlab-CI
首先检查下Gitlab的版本，是否大于8.0。从Gitlab的8.0版本开始，gitlab就全面集成了Gitlab-CI有项目默认开启。要想运行起来你的gitlab-ci,仅仅需要两个步骤：
- 第一步：在你的项目根目录添加
.gitlab-ci.yml文件 - 第二步：在你所要构建的地方（服务器）安装
gitlab-runner
就是这两步，就可以达到和Jenkins一样的效果，而且每一次合并请求（MR）或push（或者你其他的配置）都会触发CI pipeline。下面就为大家详细介绍下，具体怎么操作这些骚东西
配置 .gitlab-ci.yml文件
首先在你的项目根目录新建 .gitlab-ci.yml文件
开始做你想做的事情了，这个行为在ci中被称为job,也就是说.gitlab-ci.yml可以定义一些列的job，runner（后面会讲）会根据这些去执行相应的操作。
来看看他们长什么样子吧 （这里以我的项目为例）
stages:
- install_deps
- deploy
cache:
paths:
- node_modules
before_script:
- echo "开启任务"
variables:
Repository: "http://git.weibo.com"
install_deps:
stage: install_deps
tags:
- upload2sce
when: manual
only:
- master
script:
- echo '安装依赖'
- npm install
allow_failure: true
deploy:
stage: deploy
tags:
- upload2sce
when: manual
only:
- master
script:
- echo '删除原有的upload2sce服务!'
- pm2 delete upload2sce || true
- echo '启动upload2sce服务'
- NODE_ENV=prod pm2 start ./dist/app.js -i max --name upload2sce || true
allow_failure: true
字段解释:
这里使用了很多字段，是不是不明白代表什么意思？（当初我也不明白，来个传送门）,全特么是英文的，看不懂，这里大概介绍下吧
| 关键字 | 是否必须 | 描述 |
|---|---|---|
| script | 必须 | 定义Runner需要执行的脚本或命令 |
| image | 非必须 | 需要使用的docker镜像，请查阅该文档 |
| services | 非必须 | 定义了所需的docker服务，请查阅该文档 |
| stage | 非必须 | 定义了工作的场景阶段,默认是test |
| type | 非必须 | stage的别名，不赞成使用 |
| variables | 非必须 | 在job级别上定义的变量 |
| only | 非必须 | 定义哪些git引用（分支）适用该job |
| except | 非必须 | 定义了哪些git引用(分支)不适用该job |
| tags | 非必须 | 定义了哪些runner适用该job（runner在创建时会要求用户输入标签名来代表该runner） |
| allow_failure | 非必须 | 允许任务失败，但是如果失败，将不会改变提交状态 |
| when | 非必须 | 定义job什么时候能被执行，可以是on_success,on_failure,always或者manual |
| dependencies | 非必须 | 定义了该job依赖哪一个job，如果设置该项，你可以通过artifacts设置 |
| artifacts | 非必须 | 所谓工件。。就是在依赖项之间传递的东西，类似cache，但原理与cache不同 |
| cache | 非必须 | 定义需要被缓存的文件、文件夹列表 |
| before_script | 非必须 | 覆盖在根元素上定义的before_script |
| after_script | 非必须 | 覆盖在根元素上定义的after_script |
| environment | 非必须 | 定义让job完成部署的环境名称 |
| retry | 非必须 | 定义job失败后的自动重试次数 |
实例讲解
在ci中每一个stages是一个场景，上一个stages执行的结果，并不会传递给下一个stages.所有工作stages都是并行执行的
1、stages：上图中我们定义了两个stages阶段，分别为install_deps以及deploy
2、cache：缓存了node_modules这个文件夹,为了在构建的时候节约时间
3、before_script和after_script：顾名思义，我们每一次执行stages中的script都会执行的语句
4、variables：定义了变量，方便我们后面直接用，这个是全局变量，后面你可以在每一个stages中定义私有变量
5、install_deps：这个比较重要了，这个就是告诉runner服务器要执行的东西了，这个名字被称为job_name,你可以随便取名，但是下面的stage的名字就必须要和stages对应上（注意看，两个单词不一样的）
6、tages：这个就是runner的名字了，当你在服务器安装gitlab-runner并注册的时候，会让你给这个runner取个名字
7、when：这个牛逼了，有几个值，这里我选的是manual
8、only：这个也很厉害，告诉runner，只有master分支需要响应，当然还有其他复杂的应用，比如- /^issue-.*$/，job将会只在issue-开头的refs下执行，- tags，job只会在打了tag的分支被触发。
9、script：顾名思义这个是执行我们的语句的，（上面的例子是shell语句，当然你也可以选择其他的，但是需要根据后面你配置的runner的executor也就是执行器）
上面.gitlab-ci.yml的配置讲解完了，只有一些常用的关键字的介绍，其他的字段，大家可以google下
安装 gitlab-runner
一定先看注意事项
安装过程，我这里不多bb了，直接传送门了gitlab-runner安装指南。
注意事项：
1、尽量以root身份安装gitlab-runner，并执行。
如果你是想以root身份安装，这个可以不执行
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
在安装的时候user改为root
sudo gitlab-runner install --user=root --working-directory=/home/gitlab-runner
2、当gitlab-runner以root身份执行时，在* nix系统上，此时的配置文件在/etc/gitlab-runner/config.toml
3、当gitlab-runner以非root身份执行时，在* nix系统上，此时的配置文件在~/.gitlab-runner/config.toml
4、在注册gitlab-runner的时候,需要填写url以及token,这个是在gitlab仓库中Settings>CI/CD>General pipelines settings可以看到。
以上就是我配置的gitlab-ci，我bb完了！！
配置文件官网介绍：
https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/configuration/advanced-configuration.md
网友评论