先来说一下配置CI/CD的目标，咱们在提交代码后即提交push申请后gitLab会主动生成一个pipeLine工作，如果咱们想要在每次提交代码之后都跑一次单元测试就须要对其进行编辑，此外咱们还能够在此运行咱们自定义的脚本来实现更多需要，例如向钉钉收回推送。

上面这就是对应的配置文件——.gitlab-ci.yml

咱们在此文件中次要用到的一共就只有上面几个关键词：

stages：设置运行步骤variables：定义变量tags：设置运行环境script：设置要执行的命令

对于stages:

stages: -step1 //步骤一 -step2 //步骤二step_one: stage: step1 //申明是属于步骤一 . . .step_two:  stage: step1 //申明是属于步骤一. . .step_three  stage: step2 //申明是属于步骤二. . .

其中step_one和step_two是并行执行的。step_two在其后执行。

对于variables须要揭示的是gitLab有本人内置的变量，咱们能够间接进行应用，只须要在scrpts: 执行-env，就能够查看总共有那些变量。

对于scrpts:其作用就相当咱们本地的在我的项目根目录下的终端，输出相应指令就能够在运行相应步骤时执行。

对于tags：申明运行时所用的环境

第一个问题—在远端执行时呈现格局报错

咱们自定义的脚本在本地运行没有问题后就提交到了gitlab中通过gitlab CI/CD调用时却产生了格局谬误，例如：存在预期之外的“（”等报错。

在网上查找后所失去的问题出处都是呈现在脚本解释器的阐明上即脚本结尾的 #!/bin/bash

然而通过测试——新建test.sh在远端运行通过bash解释器运行发现并没有问题，不会产生报错；

于是我又认真地看了一边shell教程，发现这下面对于函数的阐明是这样的:

没有用到function关键字，于是我尝试着去掉它之后发现的确不报错了，但之后在远端执行时还遇到等等其余的格局问题就不在此一一赘述了。

一步一步跟着远端运行的报错解决完格局问题后的确能够在远端残缺运行咱们自定义的.sh文件，然而为什么在本地就没有这些格局问题在远端就呈现问题了过后还是没有解决，过后只是把它归纳于可能是版本不一样。

所以这样的解决办法就带来了上面第二个问题：

问题二—获取pipeLine运行工夫时遇到的问题

在gitlab给出的pipeLine自带的变量中只有pipeLine的创立工夫：CI_PIPELINE_CREATED_AT

一开始是想可不可以间接在gitLab CI 运行时取得以后工夫，间接在gitLab配置文件中计算出其时间差，然而找了很久都没有找到能够间接在gitLab CI中获取以后工夫的办法，所以只能转变思路——把CI_PIPELINE_CREATED_AT传给咱们的shell脚本，在脚本中实现这些操作。

currentTime=`date "+%Y-%m-%d %H:%M:%S"` //获取工夫while [ -n "$1" ]; do //shell脚本是以字符串为单位承受的变量case "$1" in. . .-M)    PIPE="$2" //把$2即传过来的工夫赋给PIPE    CURRENT_STAMP=$(date -d "$currentTime" +%s) //转化为工夫戳    PIPE_STAMP=$(date -d "$PIPE" +%s) //转化为工夫戳    TIME_STRING=$((CURRENT_STAMP-PIPE_STAMP)) //计算工夫戳差值    CONTENT=$CONTENT$TIME_STRING"秒"    shift 2 //将数据前移2项，即$1=$3,$2=$4...    ;;done

在本地执行之后能够失常运行，在远端运行时发现最初计算出来的差值始终为零，起初认为是pipe_line的开始工夫有误，然而查看后与预期统一，于是就尝试着在脚本中输入转化后的起始工夫戳和以后工夫戳然而发现其打印后果都为空。

起初还是认为是因为版本不同，于是又在网上找了很多在shell中对工夫戳的操作，然而基本上都是大同小异，都不实用。
到了最初才留神到tags字段，即给其设置运行环境，当我在其步骤中申明运行环境再运行就能够失常应用了。

tags: - ubuntu

问题三—获取pipeLine对应的mergeRequest的链接时遇到的问题

咱们推送到钉钉上的PipeLine的运行信息最好要附带上其对应的mergeRequest链接，然而在gitLab给出的环境变量中并没有间接给出mergeRequest链接，而是给出了CI_OPEN_MERGE_REQUESTS变量。

CI_OPEN_MERGE_REQUESTS=yunzhiclub/smart-community!9

这阐明了其对应的mergeRequest编号是9,而咱们还发现mergeRequest链接是这样的

https://gitlab.xxx.com:xxxx/xxxclub/smart-community/-/merge_requests/9

这也就是说咱们能够人为把这个链接结构进去，其中/-/merge_requests/局部是固定的，咱们能够间接在脚本中申明，而https://gitlab.xxx.com:xxxx/xxxclub/smart-community局部能够通过gitLab所给出的环境变量$CI_PROJECT_URL$mergeRequestUrl取得。

而后咱们要做的就是如何从CI_OPEN_MERGE_REQUESTS中只取得其最初的编号，咱们在shell中能够通过一下办法来从string1中取得截去string2局部的字符串string3。

string3 = ${string1#${string2}}

起初我也想过能不能间接在配置文件运行中间接批改咱们要传给脚本的contetnt即内容主体，然而通过测试，在scrpts中运行命令只能获取配置文件中内容，然而在其中定义的变量无奈被配置文件获取，所以咱们还是在脚本中进行批改。

而咱们所要去掉的局部即yunzhiclub/smart-community可由CI_PROJECT_PATH取得，所以咱们要做的就是把这些传给脚本，即

//配置文件中    - sh send-ding.sh-U $CI_PROJECT_URL$mergeRequestUrl${CI_OPEN_MERGE_REQUESTS#${CI_PROJECT_PATH}"!"  . . .
-U)    MERGE_URL="$2"    MARKDOWN_URL="### [pullRequest]($MERGE_URL)"    CONTENT=$MARKDOWN_URL"\n"$CONTENT    shift 2    ;;

然而应用CI_OPEN_MERGE_REQUESTS取得mergeRequest编号会有一个bug，比方咱们进行完一次push后开启mergeRequest这时是没有问题的，然而当咱们敞开这个mergeRequest，再进行push而后再开启mergeRequest就会发现CI_OPEN_MERGE_REQUESTS中所对应的mergeRequest还是第一次提出的mergeRequest，目前在收集相干材料后也没能找到很好的解决办法。