git cicd入门级理解

CI：持续交付

CD：持续部署

项目代码使用gitlab托管，当我们推送代码至仓库时，项目中如果编写了.yml文件，那么cicd流程就会按照文件流程自动执行

应用场景

• mr中eslint的语法检查、commit message检查、分支规范检查
• 单元测试的集成等等

代码被合并前做这些检查能大大减少交付的bug率。cicd运行时效果，可在项目侧边栏cicd/pipeline处看到

理解概念pipeline / stage / job

上图表示一个pipeline，cicd的工作流水线
上图的Build，Test， Deploy称为stage，流水线的工作阶段
上图的build-job、test-job1、...称为job，各个阶段对应的作业

怎么编写yml文件

有比较详细简单的官方文档。
vscode最好能装yml文件拓展，因为某些地方多或者少一个空格yml文件都会不能运行。

以校验mr title格式yml文件为例解释

# 定义了stage和stage的执行顺序，越靠前越优先执行
# 每个定义的stage都需要有对应的至少一个job
stages: 
  - check-merge-title
  - check-release-merge-event

# job
check-merge:
  # 将在check-merge-title stage中执行，stage值相同的job，会并行执行
  # 不可以使用没有定义的stage
  stage: check-merge-title
  # 定义该job是否执行，具体语法看文档
  # 如果一个stage中所有的job都被禁用之后，那么这个stage也不会产生了
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^(feature|refactor|bugfix|hotfix).+$/
  script:
    - echo $CI_MERGE_REQUEST_TITLE
    - title=`echo $CI_MERGE_REQUEST_TITLE | grep -E "(\[SPMDAP-[0-9]+\]\[(feat|fix|build|chore|ci|docs|style|refactor|perf|test)\]|^\!).*"`
    - >
      if [ -z "$title" ]; then
        echo "Mr title not matched"
        exit 1
      else
        echo "$title"
      fi

以上只是很基本的一个例子

yml文件有一个includes，官网对他的解释是当前文件和include文件进行智能合并。多智能呢？
其实就是一种直接的覆盖。当前文件相同字段的优先级高于include文件的。

在本地验证yml文件，避免多余的commit提交

本地安装gitlab-runner
比如

gitlab-runner exec shell [job name]

本地不支持调试所有的job，详情可见