通過 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名 的保留字

   關鍵字	是否必須	描述
   image	no	使用的docker鏡像。詳見
   services	no	使用的docker服務。詳見
   stages	no	定義構建場景
   types	no	stages的別名(不贊成使用)
   before_script	no	定義每個任務的腳本啟動前所需執行的命令
   after_script	no	定義每個任務的腳本執行結束后所需執行的命令
   variables	no	定義構建變量
   cache	no	定義哪些文件需要緩存，讓后續執行可用

2. Job 的保留字

   關鍵字	是否必須	描述
   script	yes	Runner執行的命令或腳本?？梢园鄺l命令
   image	no	使用的docker鏡像。詳見
   services	no	使用的docker服務。詳見
   stage	no	定義job stage（默認：test）
   type	no	stage的別名（已棄用）
   variables	no	定義job級別的變量
   only	no	定義一列git分支，并為其創建job
   except	no	定義一列git分支，不創建job
   tags	no	定義一列tags，用來指定選擇哪個Runner（同時Runner也要設置tags）
   allow_failure	no	允許job失敗。失敗的job不影響commit狀態
   when	no	定義何時開始job。可以是on_success，on_failure，always或者manual
   dependencies	no	定義job依賴關系，這樣他們就可以互相傳遞artifacts
   cache	no	定義應在后續運行之間緩存的文件列表
   before_script	no	重寫一組在作業前執行的命令
   after_script	no	重寫一組在作業后執行的命令
   environment	no	定義此作業完成部署的環境名稱
   coverage	no	定義給定作業的代碼覆蓋率設置

3. only and except 保留字

   關鍵字	描述
   branches	當一個分支被push上來
   tags	當一個打了tag的分支被push上來
   api	當一個pipline被piplines api所觸發調起，詳見piplines api
   external	當使用了GitLab以外的CI服務
   pipelines	針對多項目觸發器而言，當使用CI_JOB_TOKEN并使用gitlab所提供的api創建多個pipelines的時候
   pushes	當pipeline被用戶的git push操作所觸發的時候
   schedules	針對預定好的pipline而言（每日構建一類）
   triggers	用token創建piplines的時候
   web	在GitLab頁面上Pipelines標簽頁下，你按了run pipline的時候

重要的關鍵字解析

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"
   # 注意:整數和字符串一樣，對于設置變量名和變量值來說都是合法的。但浮點數是非法的。
   

   詳見此處

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
      

6. 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 # 一周后過期
   

7. Triggers

   Triggers被用于重建特定分支，tag或者commit，他是api觸發的。詳見

其他關鍵字我沒有用到因此也就沒有繼續研究了。

根據自己的需求進行 build 的設置

首先，設置 triggers。

trigger_setting_click.png

trigger_setting_click2.png

編寫 YAML，這是為 triggers 觸發：

tiggers.png

使用以下代碼觸發 build 。

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

參考文章

• Gialab YMAL 原文地址
• gitlab-ci配置詳解(一)
• gitlab-ci配置詳解(二)
• Gitlab CI yaml官方配置文件翻譯