.gitlab-ci.yml语法完整解析（三）

关于如何编写GitLab流水线，.gitlab-ci.yaml文件的关键词，已经写过两期了，gitlab-ci.yaml的关键词一共有28个，分别是 分别是 script, after_script, allow_failure, artifacts, before_script, cache, coverage, dependencies, environment, except, extends, image, include, interruptible, only, pages, parallel, release, resource_group, retry, rules, services, stage, tags, timeout, trigger, variables, when

第一期 .gitlab-ci.yml关键词完整解析（一） 讲了最常用的9个关键词的用法， script,image,artifacts,tags,cache,stage,when,only/except,

第二期.gitlab-ci.yml关键词完整解析（二）讲了11个扩展性很强的关键词的用法 before_script, after_script, dependencies, environment, extends, include, interruptible ,parallel, rules ,trigger, services

这次讲一下剩余的8个关键词 allow_failure, coverage, pages release resource_group retry timeout variables

allow_failure

allow_failure是一个布尔类型， true或false， 默认为false，表示当前任务是否允许失败。有这样一个应用场景，在使用eslint检查代码的时候，如果团队管理松散，可以将在eslint的任务下设置allow_failure: true,（其实这样还不如去掉这个任务那，手动狗头） 这样即使这个任务报错了，流水线也会继续往下走。如果一个任务设置了allow_failure: true，并且这个任务报错了，那么它将会显示黄色警告。但有种情况任务失败了也会停止的， 那就是任务设置了when: manual，即手动操作的任务。手动启动的任务，报错了就会停止，不会继续执行后续任务，除非在rule设置报错的处理逻辑。

coverage

coverage 是用于获取项目的代码覆盖率，这个配置项的值只能是一个正则表达式，官方有提供一些，在CICD的General pipelines里 覆盖率可以添加到项目的readme上，像这样的。

pages

pages是一项特殊的工作，用于将静态内容上传到GitLab，可用于为您的网站提供服务，其实就是可以托管你的网站。它具有特殊的语法，因此必须满足以下两个要求：

任何静态内容都必须放在public/目录下。 制品artifacts必须是目录public/,就是编译后的文件必须存放在public中

下面的示例将所有文件从项目的根目录移至public/目录。这里必须先创建一个.public 目录，防止根目录下已经存在public了，导致循环复制。

pages: stage: deploy script: – mkdir .public – cp -r * .public – mv .public public artifacts: paths: – public only: – master release

release关键词是用于创建一个release，即创建一个发布， 创建一个发布，可以配置这些内容

tag_name tag 名称 description 描述 name 名称 ref 提交的hash值 milestones 要关联的里程碑 released_at 创建时间 ios-release: script: – echo iOS release job release: tag_name: v1.0.0-ios description: iOS release v1.0.0 resource_group

有时在环境中同时运行多个作业或流水线时可能会导致在部署过程中出错。

为了避免这些错误，resource_group可以使用该属性来确保运行程序不会同时运行某些任务。资源组的行为类似于其他编程语言中的信号灯。

当一个任务设置了resource_group ， 同一项目的不同管道之间任务的运行是互斥的。如果属于同一资源组的多个任务同时进入队列，则运行程序仅选择其中一个作业。其他作业将等到 resource_group释放。

deploy-to-production: script: deploy resource_group: production

在这种情况下，两个deploy-to-production单独流水线中的两个作业永远无法同时运行。最后的结果及时你可以确保永远不会在生产环境中发生并发部署。

您可以为每个环境定义多个资源组。例如，当部署到物理设备时，您可能有多个物理设备。可以将每个设备部署到，但是在任何给定时间每个设备只能部署一个。

resource_group值只能包含字母，数字，-, _, /, $, {, }, .,和空格。它不能以开头或结尾/。

retry

retry可以设置一个任务的重试次数，值的类型是数字 最大是2，如果设置2，就表明该任务最多可以执行3次，其中包括2次重试。对于网络不稳定的部署，非常有用。

test: script: rspec retry: 2 timeout

timeout是用于设置一个任务的超时时间， 你也可以设置一个项目级别的超时时间。在CICD的设置中

build: script: build.sh timeout: 3 hours 30 minutes test: script: rspec timeout: 3h 30m variables

variables可以让你在yaml文件中定义变量，变量可以设置全局的，也可以是单个任务内定义。然后在script或者执行的命中使用,定义和使用的示例,

variables: DEPLOY_SITE: “https://example.com/” deploy_job: stage: deploy script: – deploy-script –url $DEPLOY_SITE –path “/” deploy_review_job: stage: deploy variables: REVIEW_PATH: “/review” script: – deploy-review-script –url $DEPLOY_SITE –path $REVIEW_PATH

变量名一般大写，使用时使用$加变量名

写在最后

到这里，.gitlab-ci.yaml的关键词解释就写完了。相信大家对GitLab流水线的配置都有个大致的印象，剩下的就是多多地锻炼。