流水线触发控制

使用workflow:rules 进行流水线控制，我们会用到Pipeline的变量，通过变量限制条件。

预定义变量参考文档：https://docs.gitlab.com//12.9/ee/ci/variables/predefined_variables.html

变量匹配语法： https://docs.gitlab.com//12.9/ee/ci/variables/README.html#supported-syntax

re2语法：https://github.com/google/re2/wiki/Syntax

排除新建分支的流水线

运行流水线您会发现，所有新创建的分支的CI_COMMIT_BEFORE_SHA为40个0。

 $ export

 declare -x CI_BUILD_BEFORE_SHA="0000000000000000000000000000000000000000"
 declare -x CI_COMMIT_BEFORE_SHA="0000000000000000000000000000000000000000"

## 流水线控制
workflow:
  rules:
    - if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"
      when: never
    - when: always

#$CI_COMMIT_REF_NAME =~ /\d-*/
#$CI_COMMIT_REF_NAME =~ /^RELEASE-*/  ||

合并流水线再进行构建验证

大家可以想像一下，如果是一个刚刚开始关注代码质量的团队，避免不了出现代码扫描的失败。改进初期出现错误很正常，如果在初期就把质量阈配置的很严格，这会导致每次提交代码都会产生错误。所以我们可以适当的放开流水线的代码扫描（也就是流水线暂时不进行质量阈检查）。

如果不扫描就无法知道代码的准确质量，所以我们准备流水线仅扫描不检查质量阈，而合并流水线会将代码质量展示在评论区。类似于这种情况我们可以设置流水线成功后才能合并。

默认是提交触发流水线运行，而设置了"流水线成功后合并"会检查原分支的最后一次提交的状态是否为success，如果是success则运行合并。我们配置流水线在出现合并请求的时候，进行代码验证。

## 流水线控制
workflow:
  rules:
    - if: $CI_MERGE_REQUEST_ID