Gitlab CI 使用高级技巧

Dear 丶 2022-11-13 11:26 163阅读 0赞

# Gitlab CI 使用高级技巧 #

通过 [iOS 使用 gitlab 自动打包][iOS _ gitlab] 我们了解到了 Gitlab 的自动化打包的简单配置。但是现在有个问题。每次提交代码都会去自动打包一遍。很多时候这不是我们想要的效果。那么 Gitlab CI 有没有其他的打包方式呢？比如按需要触发，定时触发 build 等。答案是有的。具体的操作需要了解 YML。

# Gitlab YAML 详解 #

## Gitlab 中 YAML 相关关键字与概念解析 ##

**概念**

1.  Job
    
    YAML 文件使用一系列约束叙述定义了 **Job** 启动时所要做的事情。**Job** 被定义为具名的顶级元素，并且至少包括一条脚本语句。Job 被 Runner 拿到并在 Runner 的环境下执行。**重要的是，每个 Job 都会与其他 Job 分离开来，独立进行。**如：
    
        job1:
              script: "execute-script-for-job1"
          job2:
              script: "execute-script-for-job2"
    
    上面的例子是两个在ci中能起作用的最简单的，分离的任务，每一个任务执行一条不同的命令。每条命令都会被Runners拿到并在Runner的环境下被执行。重要的是，每个任务将会独立进行，与其他任务分离开来。

**关键字**

1.  不可以被用于 Job名 的保留字
    
    <table> 
     <thead> 
      <tr> 
       <th>关键字</th> 
       <th>是否必须</th> 
       <th>描述</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>image</td> 
       <td>no</td> 
       <td>使用的docker镜像。<a href="https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fdocker%2FREADME.html" rel="nofollow">详见</a></td> 
      </tr> 
      <tr> 
       <td>services</td> 
       <td>no</td> 
       <td>使用的docker服务。<a href="https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fdocker%2FREADME.html" rel="nofollow">详见</a></td> 
      </tr> 
      <tr> 
       <td>stages</td> 
       <td>no</td> 
       <td>定义构建场景</td> 
      </tr> 
      <tr> 
       <td>types</td> 
       <td>no</td> 
       <td>stages的别名(<strong>不赞成使用</strong>)</td> 
      </tr> 
      <tr> 
       <td>before_script</td> 
       <td>no</td> 
       <td>定义每个任务的脚本启动前所需执行的命令</td> 
      </tr> 
      <tr> 
       <td>after_script</td> 
       <td>no</td> 
       <td>定义每个任务的脚本执行结束后所需执行的命令</td> 
      </tr> 
      <tr> 
       <td>variables</td> 
       <td>no</td> 
       <td>定义构建变量</td> 
      </tr> 
      <tr> 
       <td>cache</td> 
       <td>no</td> 
       <td>定义哪些文件需要缓存，让后续执行可用</td> 
      </tr> 
     </tbody> 
    </table>
2.  Job 的保留字
    
    <table> 
     <thead> 
      <tr> 
       <th>关键字</th> 
       <th>是否必须</th> 
       <th>描述</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>script</td> 
       <td>yes</td> 
       <td>Runner执行的命令或脚本。可以包含多条命令</td> 
      </tr> 
      <tr> 
       <td>image</td> 
       <td>no</td> 
       <td>使用的docker镜像。<a href="https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fdocker%2FREADME.html" rel="nofollow">详见</a></td> 
      </tr> 
      <tr> 
       <td>services</td> 
       <td>no</td> 
       <td>使用的docker服务。<a href="https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fdocker%2FREADME.html" rel="nofollow">详见</a></td> 
      </tr> 
      <tr> 
       <td>stage</td> 
       <td>no</td> 
       <td>定义job stage（默认：test）</td> 
      </tr> 
      <tr> 
       <td>type</td> 
       <td>no</td> 
       <td>stage的别名（已弃用）</td> 
      </tr> 
      <tr> 
       <td>variables</td> 
       <td>no</td> 
       <td>定义job级别的变量</td> 
      </tr> 
      <tr> 
       <td>only</td> 
       <td>no</td> 
       <td>定义一列git分支，并为其创建job</td> 
      </tr> 
      <tr> 
       <td>except</td> 
       <td>no</td> 
       <td>定义一列git分支，不创建job</td> 
      </tr> 
      <tr> 
       <td>tags</td> 
       <td>no</td> 
       <td>定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags）</td> 
      </tr> 
      <tr> 
       <td>allow_failure</td> 
       <td>no</td> 
       <td>允许job失败。失败的job不影响commit状态</td> 
      </tr> 
      <tr> 
       <td>when</td> 
       <td>no</td> 
       <td>定义何时开始job。可以是on_success，on_failure，always或者manual</td> 
      </tr> 
      <tr> 
       <td>dependencies</td> 
       <td>no</td> 
       <td>定义job依赖关系，这样他们就可以互相传递artifacts</td> 
      </tr> 
      <tr> 
       <td>cache</td> 
       <td>no</td> 
       <td>定义应在后续运行之间缓存的文件列表</td> 
      </tr> 
      <tr> 
       <td>before_script</td> 
       <td>no</td> 
       <td>重写一组在作业前执行的命令</td> 
      </tr> 
      <tr> 
       <td>after_script</td> 
       <td>no</td> 
       <td>重写一组在作业后执行的命令</td> 
      </tr> 
      <tr> 
       <td>environment</td> 
       <td>no</td> 
       <td>定义此作业完成部署的环境名称</td> 
      </tr> 
      <tr> 
       <td>coverage</td> 
       <td>no</td> 
       <td>定义给定作业的代码覆盖率设置</td> 
      </tr> 
     </tbody> 
    </table>
3.  **only** and **except** 保留字
    
    <table> 
     <thead> 
      <tr> 
       <th>关键字</th> 
       <th>描述</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>branches</td> 
       <td>当一个分支被push上来</td> 
      </tr> 
      <tr> 
       <td>tags</td> 
       <td>当一个打了tag的分支被push上来</td> 
      </tr> 
      <tr> 
       <td>api</td> 
       <td>当一个pipline被piplines api所触发调起，详见piplines api</td> 
      </tr> 
      <tr> 
       <td>external</td> 
       <td>当使用了GitLab以外的CI服务</td> 
      </tr> 
      <tr> 
       <td>pipelines</td> 
       <td>针对多项目触发器而言，当使用CI_JOB_TOKEN并使用gitlab所提供的api创建多个pipelines的时候</td> 
      </tr> 
      <tr> 
       <td>pushes</td> 
       <td>当pipeline被用户的git push操作所触发的时候</td> 
      </tr> 
      <tr> 
       <td>schedules</td> 
       <td>针对预定好的pipline而言（每日构建一类）</td> 
      </tr> 
      <tr> 
       <td>triggers</td> 
       <td>用token创建piplines的时候</td> 
      </tr> 
      <tr> 
       <td>web</td> 
       <td>在GitLab页面上Pipelines标签页下，你按了run pipline的时候</td> 
      </tr> 
     </tbody> 
    </table>

**重要的关键字解析**

1.  **after\_script**
    
    `before_script` 和 `script` 在一个上下文中是串行执行的，`after_script` 是独立执行的。所以根据执行器(在runner注册的时候，可以选择执行器，docker,shell 等)的不同，工作树之外的变化可能不可见，例如，在before\_script中执行软件的安装。
    
    你可以在任务中定义 `before_script`，`after_script`，也可以将其定义为顶级元素，定义为顶级元素将为每一个任务都执行相应阶段的脚本或命令。
2.  **stages**
    
    stages的允许定义多个，灵活的场景阶段的pipline。定义的元素的顺序决定了任务执行的顺序。例如：
    
        stages:
              - build
              - test
              - deploy
    
    1.  build场景的任务将被并行执行。test、deploy 同理
    2.  build 任务成功后，test 执行。test 成功后，deploy 执行
    3.  所有的都成功了，提交将会标记为成功
    4.  任何一步任务失败了，提交标记为失败并之后的场景，任务都不回执行。
3.  **variables**
    
    GitLab CI允许你为.gitlab-ci.yml增加变量，该变量将会被设置入任务环境。这些变量是你存储在git仓库里，并且非敏感的项目配置，例如:
    
        variables:
            DATABASE_URL: "postgres://postgres@postgres/my_database"
        # 注意:整数和字符串一样，对于设置变量名和变量值来说都是合法的。但浮点数是非法的。
    
    [详见此处][Link 1]
4.  **script**  
    script是一段由Runner执行的shell脚本，例如：
    
        job:
            script: "bundle exec rspec"
    
    这个参数也可以使用数组包涵好几条命令：
    
        job:
            script:
                - uname -a
                - bundle exec rspec
    
    **注意：**有些时候，script命令需要被单引号或者双引号所包裹。例如：当命令中包涵冒号的时候，该命令需要被引号所包裹。这样YAML解析器才知道该命令语句不是“key: value”语法的一部分。当命令中包涵以下字符时需要注意打引号:\`: \{ \} \[ \] , & \* \# ? | - < > = ! % @ \`\`
5.  **only and except**
    
    only和except两个参数说明了job什么时候将会被创建:
    
    1.  only定义了job需要执行的所在分支或者标签
    2.  except定义了job不会执行的所在分支或者标签
    
    以下是这两个参数的几条用法规则：
    
    1.  only和except如果都存在在一个job声明中，则所需引用将会被only和except所定义的分支过滤.
    2.  only和except允许使用正则
    3.  only和except允许使用指定仓库地址，但是不forks仓库
    
    例子解析：
    
    1.  job将会只在issue-开头的refs下执行，反之则其他所有分支被跳过：
        
            job:
                # use regexp
                only:
                    - /^issue-.*$/
                # use special keyword
                except:
                    - branches
    2.  job只会在打了tag的分支，或者被api所触发，或者每日构建任务上运行，
        
            job:
                # use special keywords
                only:
                    - tags      # tag 分支 commit 之后触发
                    - triggers  # API 触发
                    - schedules # 每日构建触发
    3.  job将会在父仓库gitlab-org/gitlab-ce的非master分支有提交时运行。
        
            job:
                only:
                    - branches@gitlab-org/gitlab-ce
                except:
                    - master@gitlab-org/gitlab-ce
    4.  在计划被触发时或者master分支被push时触发，并且先决条件是kubernetes服务是活跃的（你启用了kubernetes服务作为执行器，相关请看gitlab ci runner的文档，ce用户一般用求不到）
        
            job:
                only:
                    refs:
                        - master
                        - schedules
                    kubernetes: active

1.  **artifacts**
    
    artifacts 被用于在 job 作业成功后将制定列表里的文件或文件夹附加到 job 上，传递给下一个 job ，如果要在两个 job 之间传递 artifacts，你必须设置dependencies,下面有几个例子
    
    1.  传递所有binaries和.config：
        
            artifacts:
                paths:
                    - binaries/
                    - .config
    2.  传递所有git没有追踪的文件
        
            artifacts:
                untracked: true
    3.  传递binaries文件夹里所有内容和git没有追踪的文件
        
            artifacts:
                untracked: true
                paths:
                    - binaries/
    4.  禁止传递来的artifact:
        
            job:
                stage: build
                script: make build
                dependencies: []
    5.  只为打tags的行为创建artifacts。artifacts将会在job执行完毕后送到GitLab ui前台来，你可以直接下载它(tag、details、pipeline 的下载按钮上都会出现)。
        
            default-job:
                script:
                    - mvn test -U
                except:
                    - tags
            
            release-job:
                script:
                    - mvn package -U
                artifacts:
                    paths:
                        - target/*.war
                    only:
                        - tags
    
    **artifacts:name**
    
    name指令允许你对artifacts压缩包重命名，你可以为每个artifect压缩包都指定一个特别的名字，这样对你在gitlab上下载artifect的压缩包有用
    
        job:
            artifacts:
                name: "$CI_JOB_NAME"
    
    **artifacts:when**  
    用于job失败或者未失败时使用。artifacts:when能设置以下值：
    
    1.  on\_success 这个值是默认的，当job成功时上传artifacts
    2.  on\_failure 当job执行失败时，上传artifacts
    3.  always 不管失败与否，都上传
    
        job:
            artifacts:
                when: on_failure    #当失败时上传artifacts
    
    **artifacts:expire\_in**  
    artifacts:expire\_in 用于设置 artifacts 上传包的失效时间. 如果不设置，artifacts 的打包是永远存在于 gitlab上 的。当指定 artifacts 过期时间的时候, 在该期间内，artifacts 包将储存在 gitLab 上。并且你可以在 job 页面找到一个 keep 按钮，按了以后可以覆盖过期时间，让 artifacts 永远存在。过期之后，用户将无法访问到 artifacts 包。时间的例子如下:
    
     *  '3 mins 4 sec'
     *  '2 hrs 20 min'
     *  '2h20min'
     *  '6 mos 1 day'
     *  '47 yrs 6 mos and 4d'
     *  '3 weeks and 2 days'
    
        job:
            artifacts:
                expire_in: 1 week # 一周后过期
2.  **Triggers**
    
    Triggers被用于重建特定分支，tag或者commit，他是api触发的。[详见][Link 2]

其他关键字我没有用到因此也就没有继续研究了。

# 根据自己的需求进行 build 的设置 #

首先，设置 triggers。

![add2db063dfd0d0840a6420d2580d2e4.png][]

trigger\_setting\_click.png

![1df2ee1468e61af66a9bd20a334f77a5.png][]

trigger\_setting\_click2.png

编写 YAML，这是为 triggers 触发：

![a39693b5e46e837b2f7fe0ffa896e4c6.png][]

tiggers.png

使用以下代码触发 build 。

curl -X POST -F token=你的token -F ref=你的Branch名称 https://your.gitlab.address/api/v4/projects/160/trigger/pipeline

# 参考文章 #

*  [Gialab YMAL 原文地址][Gialab YMAL]
 *  [gitlab-ci配置详解(一)][gitlab-ci]
 *  [gitlab-ci配置详解(二)][gitlab-ci 1]
 *  [Gitlab CI yaml官方配置文件翻译][Gitlab CI yaml]

[iOS _ gitlab]: https://www.jianshu.com/p/c835adc414ed
[Link 1]: https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fvariables%2FREADME.html
[Link 2]: https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Ftriggers%2FREADME.html
[add2db063dfd0d0840a6420d2580d2e4.png]: /images/20221022/b30be237982d44b296cba572a2ad3fe9.png
[1df2ee1468e61af66a9bd20a334f77a5.png]: /images/20221022/f909fbfcd15d4cb8b7a8ad28a0911387.png
[a39693b5e46e837b2f7fe0ffa896e4c6.png]: /images/20221022/35ad08535ef94920b73b3e3677daee34.png
[Gialab YMAL]: https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fyaml%2FREADME.html%23stages
[gitlab-ci]: https://links.jianshu.com/go?to=https%3A%2F%2Fsegmentfault.com%2Fa%2F1190000011881435
[gitlab-ci 1]: https://links.jianshu.com/go?to=https%3A%2F%2Fsegmentfault.com%2Fa%2F1190000011890710
[Gitlab CI yaml]: https://links.jianshu.com/go?to=https%3A%2F%2Fsegmentfault.com%2Fa%2F1190000010442764