配置.gitlab-ci.yml - 自定义流水线

参考官网：
gitlab持续集成流水线配置

结合官网，以一种探索性的方式，展示gitlab持续集成流水线的搭建过程。

环境

软件	版本
gitlab	11.5.1
gitlab-runner	11.5.1

第一章 gitlab持续集成流水线 - 创建“流水线”

---

简介

如果您对“持续集成”“流水线”概念还处于模糊阶段，那么这节也许很适合您。
持续集成，对于当前的gitlab ci，个人理解，持续性表现在 gitlab push提交动作触发流水线、定时任务流水线；集成性的话想对较弱，至少是需要通过配置来加强。
流水线，基本上就是需要配置来实现，完成一整套操作：代码质量检查、单元测试、构建、接口测试等等。类似于工厂的流水线，毛件（代码等）放到传送带上，进行一系列检查（代码质量检查、测试）、处理（构建等），直到生成成品（可运行文件文件夹）或其他（出现异常、代码编译构建错误等）。

本章有两个目的，一是最简单的方式配置gitlab-ci流水线（暂时免去实际的操作），二是整体感受下gitlab-ci流水线。
还有，gitlab-ci流水线触发有三种方式，其中可通过“only”和“except”配置自定义触发方式：

• 默认方式，gitlab服务器接收到更新后自动触发
• Pipelines页面，“Run Pipeline”按钮，当然，单击后还需要选择分支，选择性添加变量，“Create pipeline”
  
  
• TOKEN+ Pipeline triggers API，http请求触发，创建token，然后如下页面往下翻会有调用方式详情。
  

简单例子

在代码库创建配置文件 .gitlab-ci.yml ，如下
配置stages和jobs，stages基本就是流水线的顺序，jobs有“sonar_analyze”和“my_build”，在此处，一个stage对应一个job，当然可以一个stage对应多个job。
job的tags，用于job与gitlab-runner关联配置（赶稿中。。。），只有打了这些标签的runner才配得上run我。

stages:
  - analyze
  - build
sonar_analyze:
  script:
    - echo sonar_analyze
    - echo job done 
  tags:
    - master
my_build:
  script:
    - echo my_build
    - echo job done 
  tags:
    - master

第二章 gitlab持续集成流水线 - 添加自定义操作

---

简介

在上章我们已经建立起自己的流水线，接下来，该添加实际应用中的操作步骤了。
需要重点说下的是，docker镜像的使用，这里是直接在(docker hub官网)[https://hub.docker.com/]找的，所以会出现有些工具没有的情况，在工程使用中是应该避免的，自动化成功率和这种流程精简密切相关的。

实用例子

# stages