参考文章：[花了两天，搞了Gitlab-Runner CI/CD实现自动化部署，可比Jenkins香太多啦！！！！_gitlab的cicd取代jenkens-CSDN博客]
Gitlab的CI需要安装CI专用的GitLab Runner，否则跑不起来
拉取安装Runner
docker run -d --name runner --network=host --restart always -v /srv/gitlab-runner/config:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
首先，docker ci的runner容器，一台机器只运行一个即可。如果是注册多个Runner，就直接进入到镜像内容，直接进行注册即可！！
不同的Runner可以注册不同CI配置类型
CI Runner需要在管理中心进行搭建，这里我已经注册了一个标签为docker的Runner，下面，我要在同一个Docker的镜像下面，再注册一个名字为UAT的CI Runner
创建Runner，后面的命令需要到Runner的内部才能绑定
打开控制台，进入CI的Images内部
docker exec -it Runner的imageID /bin/bash
进入CI Runner内部后，执行命令
输入注册命令：gitlab-runner register
回车继续下一步，输入之前页面上生成的URL
csharp
给注册的Runner取个名字
注意这里非常关键，不同的执行类型代表着 .gitlab-ci.yml CI配置文件里命令的执行类型
一般来说，都是在配置文件里写shell脚本。当然，也可以根据不同的类型选择
这里选择shell作为执行器类型
但无论选什么类型，要跟自己的CI配置文件能够对应上，坚决不能出现配置了shell而CI配置文件里写docker命令的行为！总之要保证对应
创建完毕
csharp
查看配置文件，发现新注册的Runner配置： cat /etc/gitlab-runner/config.toml 
创建完毕，返回Runner界面，查看已注册的Runner，新注册的已经Runner已经上来了
此时只需要在.gitlabci.yml文件里，指定好CI的tag即可，这样就可以指定运行的runner了
有CI文件的项目，在代码变更提交后，发生Commit项目里会自动进行CI操作
两个CI的Runner按配置文件里的顺序进行build
已经可以正常工作了，这个test的标题是配置在CI的stage里面
