通過 iOS 使用 gitlab 自動(dòng)打包 我們了解到了 Gitlab 的自動(dòng)化打包的簡單配置。但是現(xiàn)在有個(gè)問題剪芥。每次提交代碼都會(huì)去自動(dòng)打包一遍。很多時(shí)候這不是我們想要的效果琴许。那么 Gitlab CI 有沒有其他的打包方式呢税肪？比如按需要觸發(fā)，定時(shí)觸發(fā) build 等榜田。答案是有的益兄。具體的操作需要了解 YML。

Gitlab YAML 詳解

Gitlab 中 YAML 相關(guān)關(guān)鍵字與概念解析

概念

1. Job

   YAML 文件使用一系列約束敘述定義了 Job 啟動(dòng)時(shí)所要做的事情箭券。Job 被定義為具名的頂級(jí)元素净捅，并且至少包括一條腳本語句。Job 被 Runner 拿到并在 Runner 的環(huán)境下執(zhí)行辩块。重要的是蛔六，每個(gè) Job 都會(huì)與其他 Job 分離開來，獨(dú)立進(jìn)行废亭。如：

     job1:
         script: "execute-script-for-job1"
     job2:
         script: "execute-script-for-job2"
   

   上面的例子是兩個(gè)在ci中能起作用的最簡單的国章，分離的任務(wù)，每一個(gè)任務(wù)執(zhí)行一條不同的命令豆村。每條命令都會(huì)被Runners拿到并在Runner的環(huán)境下被執(zhí)行液兽。重要的是，每個(gè)任務(wù)將會(huì)獨(dú)立進(jìn)行掌动，與其他任務(wù)分離開來四啰。

關(guān)鍵字

1. 不可以被用于 Job名 的保留字

   關(guān)鍵字	是否必須	描述
   image	no	使用的docker鏡像。詳見
   services	no	使用的docker服務(wù)粗恢。詳見
   stages	no	定義構(gòu)建場景
   types	no	stages的別名(不贊成使用)
   before_script	no	定義每個(gè)任務(wù)的腳本啟動(dòng)前所需執(zhí)行的命令
   after_script	no	定義每個(gè)任務(wù)的腳本執(zhí)行結(jié)束后所需執(zhí)行的命令
   variables	no	定義構(gòu)建變量
   cache	no	定義哪些文件需要緩存拟逮，讓后續(xù)執(zhí)行可用

2. Job 的保留字

   關(guān)鍵字	是否必須	描述
   script	yes	Runner執(zhí)行的命令或腳本∈首遥可以包含多條命令
   image	no	使用的docker鏡像敦迄。詳見
   services	no	使用的docker服務(wù)。詳見
   stage	no	定義job stage（默認(rèn)：test）
   type	no	stage的別名（已棄用）
   variables	no	定義job級(jí)別的變量
   only	no	定義一列g(shù)it分支，并為其創(chuàng)建job
   except	no	定義一列g(shù)it分支罚屋，不創(chuàng)建job
   tags	no	定義一列tags苦囱，用來指定選擇哪個(gè)Runner（同時(shí)Runner也要設(shè)置tags）
   allow_failure	no	允許job失敗。失敗的job不影響commit狀態(tài)
   when	no	定義何時(shí)開始job脾猛∷和可以是on_success，on_failure猛拴，always或者manual
   dependencies	no	定義job依賴關(guān)系羹铅，這樣他們就可以互相傳遞artifacts
   cache	no	定義應(yīng)在后續(xù)運(yùn)行之間緩存的文件列表
   before_script	no	重寫一組在作業(yè)前執(zhí)行的命令
   after_script	no	重寫一組在作業(yè)后執(zhí)行的命令
   environment	no	定義此作業(yè)完成部署的環(huán)境名稱
   coverage	no	定義給定作業(yè)的代碼覆蓋率設(shè)置

3. only and except 保留字

   關(guān)鍵字	描述
   branches	當(dāng)一個(gè)分支被push上來
   tags	當(dāng)一個(gè)打了tag的分支被push上來
   api	當(dāng)一個(gè)pipline被piplines api所觸發(fā)調(diào)起，詳見piplines api
   external	當(dāng)使用了GitLab以外的CI服務(wù)
   pipelines	針對(duì)多項(xiàng)目觸發(fā)器而言愉昆，當(dāng)使用CI_JOB_TOKEN并使用gitlab所提供的api創(chuàng)建多個(gè)pipelines的時(shí)候
   pushes	當(dāng)pipeline被用戶的git push操作所觸發(fā)的時(shí)候
   schedules	針對(duì)預(yù)定好的pipline而言（每日構(gòu)建一類）
   triggers	用token創(chuàng)建piplines的時(shí)候
   web	在GitLab頁面上Pipelines標(biāo)簽頁下职员，你按了run pipline的時(shí)候

重要的關(guān)鍵字解析

1. after_script

   before_script 和 script 在一個(gè)上下文中是串行執(zhí)行的，after_script 是獨(dú)立執(zhí)行的跛溉。所以根據(jù)執(zhí)行器(在runner注冊(cè)的時(shí)候焊切，可以選擇執(zhí)行器，docker,shell 等)的不同芳室，工作樹之外的變化可能不可見专肪，例如，在before_script中執(zhí)行軟件的安裝堪侯。

   你可以在任務(wù)中定義 before_script嚎尤，after_script，也可以將其定義為頂級(jí)元素伍宦，定義為頂級(jí)元素將為每一個(gè)任務(wù)都執(zhí)行相應(yīng)階段的腳本或命令诺苹。

2. stages

   stages的允許定義多個(gè)，靈活的場景階段的pipline雹拄。定義的元素的順序決定了任務(wù)執(zhí)行的順序收奔。例如：

       stages:
         - build
         - test
         - deploy
   

   1. build場景的任務(wù)將被并行執(zhí)行。test滓玖、deploy 同理
   2. build 任務(wù)成功后坪哄，test 執(zhí)行。test 成功后势篡，deploy 執(zhí)行
   3. 所有的都成功了翩肌，提交將會(huì)標(biāo)記為成功
   4. 任何一步任務(wù)失敗了，提交標(biāo)記為失敗并之后的場景禁悠，任務(wù)都不回執(zhí)行念祭。

3. variables

   GitLab CI允許你為.gitlab-ci.yml增加變量，該變量將會(huì)被設(shè)置入任務(wù)環(huán)境碍侦。這些變量是你存儲(chǔ)在git倉庫里粱坤，并且非敏感的項(xiàng)目配置隶糕，例如:

   variables:
       DATABASE_URL: "postgres://postgres@postgres/my_database"
   # 注意:整數(shù)和字符串一樣，對(duì)于設(shè)置變量名和變量值來說都是合法的站玄。但浮點(diǎn)數(shù)是非法的枚驻。
   

   詳見此處

4. script
   script是一段由Runner執(zhí)行的shell腳本，例如：

   job:
       script: "bundle exec rspec"
   

   這個(gè)參數(shù)也可以使用數(shù)組包涵好幾條命令：

   job:
       script:
           - uname -a
           - bundle exec rspec
   

   注意：有些時(shí)候株旷，script命令需要被單引號(hào)或者雙引號(hào)所包裹再登。例如：當(dāng)命令中包涵冒號(hào)的時(shí)候，該命令需要被引號(hào)所包裹晾剖。這樣YAML解析器才知道該命令語句不是“key: value”語法的一部分锉矢。當(dāng)命令中包涵以下字符時(shí)需要注意打引號(hào):`: { } [ ] , & * # ? | - < > = ! % @ ``

5. only and except

   only和except兩個(gè)參數(shù)說明了job什么時(shí)候?qū)?huì)被創(chuàng)建:

   1. only定義了job需要執(zhí)行的所在分支或者標(biāo)簽
   2. except定義了job不會(huì)執(zhí)行的所在分支或者標(biāo)簽

   以下是這兩個(gè)參數(shù)的幾條用法規(guī)則：

   1. only和except如果都存在在一個(gè)job聲明中，則所需引用將會(huì)被only和except所定義的分支過濾.
   2. only和except允許使用正則
   3. only和except允許使用指定倉庫地址齿尽，但是不forks倉庫

   例子解析：

   1. job將會(huì)只在issue-開頭的refs下執(zhí)行沽损，反之則其他所有分支被跳過：

      job:
          # use regexp
          only:
              - /^issue-.*$/
          # use special keyword
          except:
              - branches
      

   2. job只會(huì)在打了tag的分支，或者被api所觸發(fā)雕什，或者每日構(gòu)建任務(wù)上運(yùn)行缠俺，

      job:
          # use special keywords
          only:
              - tags      # tag 分支 commit 之后觸發(fā)
              - triggers  # API 觸發(fā)
              - schedules # 每日構(gòu)建觸發(fā)
      

   3. job將會(huì)在父倉庫gitlab-org/gitlab-ce的非master分支有提交時(shí)運(yùn)行显晶。

      job:
          only:
              - branches@gitlab-org/gitlab-ce
          except:
              - master@gitlab-org/gitlab-ce
      

   4. 在計(jì)劃被觸發(fā)時(shí)或者master分支被push時(shí)觸發(fā)贷岸，并且先決條件是kubernetes服務(wù)是活躍的（你啟用了kubernetes服務(wù)作為執(zhí)行器，相關(guān)請(qǐng)看gitlab ci runner的文檔磷雇，ce用戶一般用求不到）

      job:
          only:
              refs:
                  - master
                  - schedules
              kubernetes: active
      

6. artifacts

   artifacts 被用于在 job 作業(yè)成功后將制定列表里的文件或文件夾附加到 job 上偿警，傳遞給下一個(gè) job ，如果要在兩個(gè) job 之間傳遞 artifacts唯笙，你必須設(shè)置dependencies,下面有幾個(gè)例子

   1. 傳遞所有binaries和.config：

      artifacts:
          paths:
              - binaries/
              - .config
      

   2. 傳遞所有g(shù)it沒有追蹤的文件

      artifacts:
          untracked: true
      

   3. 傳遞binaries文件夾里所有內(nèi)容和git沒有追蹤的文件

      artifacts:
          untracked: true
          paths:
              - binaries/
      

   4. 禁止傳遞來的artifact:

      job:
          stage: build
          script: make build
          dependencies: []
      

   5. 只為打tags的行為創(chuàng)建artifacts螟蒸。artifacts將會(huì)在job執(zhí)行完畢后送到GitLab ui前臺(tái)來，你可以直接下載它(tag崩掘、details七嫌、pipeline 的下載按鈕上都會(huì)出現(xiàn))。

      default-job:
          script:
              - mvn test -U
          except:
              - tags
      
      release-job:
          script:
              - mvn package -U
          artifacts:
              paths:
                  - target/*.war
              only:
                  - tags
      

   artifacts:name

   name指令允許你對(duì)artifacts壓縮包重命名苞慢，你可以為每個(gè)artifect壓縮包都指定一個(gè)特別的名字诵原，這樣對(duì)你在gitlab上下載artifect的壓縮包有用

   job:
       artifacts:
           name: "$CI_JOB_NAME"
   

   artifacts:when
   用于job失敗或者未失敗時(shí)使用。artifacts:when能設(shè)置以下值：

   1. on_success 這個(gè)值是默認(rèn)的挽放，當(dāng)job成功時(shí)上傳artifacts
   2. on_failure 當(dāng)job執(zhí)行失敗時(shí)绍赛，上傳artifacts
   3. always 不管失敗與否，都上傳

   job:
       artifacts:
           when: on_failure    #當(dāng)失敗時(shí)上傳artifacts
   

   artifacts:expire_in
   artifacts:expire_in 用于設(shè)置 artifacts 上傳包的失效時(shí)間. 如果不設(shè)置辑畦，artifacts 的打包是永遠(yuǎn)存在于 gitlab上 的吗蚌。當(dāng)指定 artifacts 過期時(shí)間的時(shí)候, 在該期間內(nèi)，artifacts 包將儲(chǔ)存在 gitLab 上纯出。并且你可以在 job 頁面找到一個(gè) keep 按鈕蚯妇，按了以后可以覆蓋過期時(shí)間敷燎，讓 artifacts 永遠(yuǎn)存在。過期之后侮措，用戶將無法訪問到 artifacts 包懈叹。時(shí)間的例子如下:

   • '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觸發(fā)的澄成。詳見

其他關(guān)鍵字我沒有用到因此也就沒有繼續(xù)研究了。

根據(jù)自己的需求進(jìn)行 build 的設(shè)置

首先畏吓，設(shè)置 triggers墨状。

trigger_setting_click.png

trigger_setting_click2.png

編寫 YAML，這是為 triggers 觸發(fā)：

tiggers.png

使用以下代碼觸發(fā) 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官方配置文件翻譯