紧接上文，我们在服务器上下载并配置了gitlab-runner这个工具，并且在gitlab上项目的设置处看到亮起了绿灯：
今天我们继续带着各种问题来思考，为什么要带着问题？因为这是在帮大家快速树立起独立思考和创新的重要步骤。
问题1：还剩下什么没有做？
答：我们配置好了这个gitlab-runner之后，相当于你已经找到了帮你干活的人，但是具体要干什么，你总要交代清楚吧？
所以，我们接下来的事情就是，想办法告诉它当代码更新后，要做什么？按照我们一开始的计划，我们想让它自动去我们服务器的代码项目根目录下去执行git pull来拿到最新代码。
问题2：我们要在哪去提前设置gitlab-runner要执行的命令？
答：按常理说，应该是有个类似文件的东西，让我们把要执行的命令写在上面，然后gitlab-runner认识这个文件（应该需要特定文件名）。才会达到自动执行的目的。
问题3：这个装着执行命令的文件应该起名叫什么？放在哪？在哪修改？
答：这种时候，就不是我们瞎蒙的了，文件叫什么名这种问题很显然是人家官方规定好的，所以我们简单一百度就知道了答案；
文件名：.gitlab-ci.yml
文件位置：项目根目录下，和.git命令等放在一起。
（我的项目叫for_test，点开头的文件证明是隐藏文件）
在哪修改：既然在项目根目录，那我们可以本地修改然后git push上传，也可以在gitlab网页上在线创建和修改。
（本地修改）：
（在线修改）：
是的，你没看错，这个文件不需要像其他文件那样在库里修改，而直接在左侧菜单ci/cd 下的editor就可以修改，非常方便。
问题4：这个文件的内容应该是什么？什么命令语言？
答：文件内容应该是按照gitlab-runner官方制定的一些固定格式语法来写，不然gitlab-runner看不懂。 具体命令语言上，很显然是shell命令。当然如果你要做的事很多也复杂，更想用python的脚本语言，那么你应该提前在某个位置准备好这个.py脚本文件，然后在这个.gitlab-ci.yml 里用shell命令调用这个py文件即可：python3 xxx/xxx/xx.py
再来看文件的具体规则，这种东西我们一百度就会有很多，官方的则更全，某些博客总结的也不错，不过对我们新手第一次常识来说还是过于复杂了，所以我这里写了个超简单的，我们先通过这个简单的写法来初步明白这个文件的格式规则：
注意看，这个文件是靠缩进空格来分段的，目前最外层只有俩个: stages 和 test ，他们是干嘛的？可以随便起名么？
答： 他们是固定写法，强烈建议不要随便改，当然当你学熟练了会发现很多一开始以为的固定写法都是可以设置的，只是我在你初学的时候不想让你觉得太复杂，很多问题告诉你死记硬背，你反而会觉得简单，而更有信心。
stages 是告诉gitlab-runner要干几个大活，目前我就写了一个大活，叫test。然后下面的test是一个大活，它里面的stage就相当于名字，对外叫test。靠这个stage的值为test，上面的stages才确定是这个大活。
那么这个大活内都要干啥呢？
stage：test 是表明了的名字。
only：main 是表示只监控代码分支-main，只有main的代码更新才会执行这个文件。
script：就是我说的要在服务器上执行的一大堆shell命令了。
tags：sss 就是让我提前设置在服务器上注册时候的那个管家，我图里叫sss，前面教程叫wqrf1 大家注意。
了解了这个脚本的基础，我们之后就可以多写几个大活，让stages来顺序执行这些大活，比如有的是负责拉代码，有的是负责同步数据库，有的是初始化项目一些开关配置，有的是执行某个py文件来进行自测，有的是发送什么命令请求来执行自动化测试脚本等等.... 你可以给你公司产品app的项目代码设置一下，来执行你提前写好的自动化测试用例脚本。
问题：这个文件调试和执行时机是什么？
答：前面我们知道，这个文件当监控的分支代码或文件被改变了就会自动让gitlab-runner去执行写好的.gitlab-ci.yml文件内容。但是我们想一个事儿，就是这个文件本身也属于这个项目内的文件内容呀~ 所以就算我们其他文件都不改，只改变这个文件的内容也会触发gitlab-runner来执行。
所以我们在gitlab网页上，在线修改.gitlab-ci.yml 然后保存，也一样可以触发才对，这样我们调试就方便了~
注意，当你用公司的产品时，尽量单弄个分支代码来不断调试这个gitlab-runner ，千万不要在主干分支:master或main 上，不然不断的重新部署，会让公司的同事没法用主干环境正常工作了，这很重要，因为你一开始可能要调试很多次，一定会挨揍的，亲测。
当完全调试ok了，再给改成监控主干分支。
问题：这个ci/cd文件.gitlab-ci.yml 执行后的结果在哪看？
答：在线看就行了，gitlab里：
看上图，这里记录了每次这个文件执行的结果，有成功，也有失败，就像人生啊~
若想看具体成功或失败的输出，来方便调试。可以直接点击passed/failed按钮进入：(也可以直接点击左侧菜单-CI/Cd-Jobs)
点击jobs,然后再点击这个按钮，就可以看到了：
看上图，那些绿色的字，是执行我们文件中设计好的命令。下面白色就是正常的输出。可以看到我打印了一句话：“开始自动部署” ，下面就真的显示了。
然后正常的进入项目根目录，执行git pull命令，也可以正常获取最新代码和文件了。
最后 ，自动输出了一句绿色的：job succeeded ，证明执行成功~
失败的也会显示好红色的输出，让你明白自己菜在哪里....
问题：有的同学发现，什么都没改，第一次可以执行成功，再次执行就会报错。
答：这个问题我当时也遇到了，为什么第一次可以成功，之后开始失败。后来经过艰苦的查询，发现是服务器git命令工具版本太低导致，旧版本的git不支持这么新颖的插件，导致重复后缓存问题报错。
修复的办法就是升级git。你可以直接升级，也可以卸载旧的重新下载很新的版本。这种更新问题随便百度有的是答案。
安装git 2 #安装源 yum install http://opensource.wandisco.com/centos/7/git/x86_64/wandisco-git-release-7-2.noarch.rpm #安装git yum install git #更新git yum update git
至此，如果你很幸运成功了，那么恭喜你可以继续深造这个CI/CD了，比如用测试平台和这个联动起来，让gitlab-runner发送一条http请求给测试平台，测试平台来执行对应某测试环境的测试用例脚本，效果贼魔幻。
