gitlab-ci配置詳解(一)

近期由於折騰gitlab-ci，專門去翻了不少文檔，想一想貌似本身挺傻的。按照官網教程原本biubiubiu就弄好了，非本身折騰了好幾天，還沒啥積累，真是做。想一想惟一能積累的就是ci的配置詳解了。

該文基於最新版GitLab Community Edition 10.1.1和GitLab Runner9.5.1-1

---

使用.gitlab-ci.yml配置你的項目

這篇文檔描述了.gitlab-ci.yml的用法，本文件是被gitlab runner用於管理你的項目任務。

若是你想要快速查看Gitlab CI的介紹，請點擊這裏 快速開始嚮導

.gitlab-ci.yml

從版本7.12開始,GitLab CI使用YAML文件(.gitlab-ci.yml)對你的項目進行配置。該文件放置在你項目的根目錄下，而且包涵了你的項目如何被編譯的描述語句。

YAML文件使用一系列約束敘述定義了「任務」啓動時所要作的事情。「任務」被定義爲具名的頂級元素，而且至少包括一條腳本語句：

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

上面的例子是兩個在ci中能起做用的最簡單的，分離的任務，每個任務執行一條不一樣的命令。

固然了，一條命令會當即在克隆的倉庫中執行一句語句（例如：./configure;make;make install）或者啓動一個腳本(例如test.sh)

任務會被Runners拿到並在Runner的環境下被執行。重要的是，每一個任務將會獨立進行，與其餘任務分離開來。

YAML語法容許咱們使用更復雜的任務聲明，例以下面的例子：

# docker鏡像
image: ruby:2.1
# 依賴的docker服務
services:
  - postgres
# 開始執行腳本前所需執行腳本
before_script:
  - bundle install
# 腳本執行完後的鉤子，執行所需腳本
after_script:
  - rm secrets
# 該ci pipeline適合的場景
stages:
  - build
  - test
  - deploy
# 定義的任務1
job1:
  # 場景爲構建
  stage: build
  # 所需執行的腳本
  script:
    - execute-script-for-job1
  # 在哪一個分支上可用
  only:
    - master
  # 指定哪一個ci runner跑該工做
  tags:
    - docker

如下是一些不可被用於任務名的保留字：

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

image and services

這兩個選項容許咱們指定任務運行時所需的自定義的docker鏡像和服務，這兩個選項的配置在如下文檔中有涉及

before_script

before_script是用於定義一些在全部任務執行前所需執行的命令, 包括部署工做（可是是在job環境手動恢復以後執行）。能夠接受一個數組或者多行字符串。

after_script

在GitLab 8.7引進，須要GitLab Runner v1.2以上的版本

after_script用於定義全部job執行事後須要執行的命令. 能夠接受一個數組或者多行字符串。

注意: before_script和script在一個上下文中是串行執行的，after_script是獨立執行的，因此根據執行器(在runner註冊的時候，能夠選擇執行器，docker,shell,blabla...)的不一樣，工做樹以外的變化可能不可見，例如，在before_script中執行軟件的安裝。

注意:你能夠在任務中定義before_script，after_script，也能夠將其定義爲頂級元素，定義爲頂級元素將爲每個任務都執行相應階段的腳本或命令

stages

stages是用於定義場景階段，能夠被任務所使用用於定義所屬場景階段。stages的容許定義多個，靈活的場景階段的pipline。

stages定義的元素的順序決定了任務執行的順序:

1.任務指定的stage名相同，該多個任務將並行執行(可是通過測試，貌似也是按照A-Z的頭字母順序順序執行的。。只是GitLab-UI上看着是並行。。。)
2.下一個場景階段的任務將會在前一個場景階段的任務都完成的狀況下執行

讓咱們來思考一下下面的例子，下面的例子定義了3個場景階段:

stages:
  - build
  - test
  - deploy

1.首先, 全部build場景的任務將被並行執行.
2.若是全部build場景的任務都成功了, test場景的全部任務將會並行執行.
3.若是全部test場景的任務都成功了, depoly場景的全部任務將會執行.
4.若是全部depoly場景的任務都成功了, 提交將會標記爲成功.
5.若是其中某一步場景某一個任務失敗了, 那麼提交將會被標記爲失敗，而且以後的場景和任務將不會執行.

這裏也有兩種邊緣狀況值得一說：

1. 若是在.gitlab-ci.yml中沒有定義stages,build、test、deploy將是任務可設定的場景階段的默認值.
2. 若是一個任務沒有指定場景階段，該任務將會默認爲test場景階段，

types

不同意使用，在將來的發行版中將會被移除，請使用stages代替

爲stages的別名

variables

由GitLab Runner v0.5.0引入

GitLab CI容許你爲.gitlab-ci.yml增長變量，該變量將會被設置入任務環境。這些變量是你存儲在git倉庫裏，而且非敏感的項目配置，例如:

variables:
  DATABASE_URL: "postgres://postgres@postgres/my_database"

注意:整數和字符串同樣，對於設置變量名和變量值來講都是合法的。但浮點數是非法的。

這些變量在以後的全部命令和腳本中都能使用。而且YAML文件定義的變量一樣會被設置到全部被用戶建立的服務容器裏。重要的是，變量也能夠定義在一個任務級別中

job1:
    variables:
        STATIC_PATH: "./"

除了用戶定義的變量，你的運行環境中也有一些由Runner射只的變量，其中一個例子是 CI_COMMIT_REF_NAME變量，該變量的值表示了正在構建的項目的分支或者標籤名。除了用戶設置的變量以外，gitlab的ui也能設置一些「祕密變量」。詳細見文檔【variables】

cache

注意：

• 由gitlab runner v0.7.0引入
• 在GitLab 9.2以前，緩存將會在artifacts被下載以後（artifacts詳見配置詳解二）被重置
• 在此以後，緩存將會在artifacts被下載以前被重置

cache用於指定一些須要在任務間進行緩存的文件和目錄，你只能使用項目工做空間內的路徑來指定緩存。下面是一個例子

stages:
    - pre_build
    - build
cache:
    key: ${CI_BUILD_REF_NAME}
    paths:
        - node_modules/
pre_build:
    stage: pre_build
    script:
        - npm install

在GitLab9.0之後，咱們默認啓用了pipelines和jobs之間的緩存共享！

若是cache定義在jobs的做用域外(就是作爲頂級元素),則這意味着這個設置是全局的，全部任務都會使用該定義(使用的意思是Checking cache for default，
Successfully extracted cache。從默認緩存存儲位置拉取緩存)。

緩存binaries和.config下的全部文件(我實驗過了，緩存定義在job裏，1個是沒有用的，兩個job定義了相同的緩存，他們纔會從 default cache path 裏被找到)

rspec:
  script: test
  cache:
    paths:
    - binaries/
    - .config

緩存全部未追蹤的文件：

rspec:
  script: test
  cache:
    untracked: true

緩存binaries文件夾和全部未追蹤的文件

rspec:
  script: test
  cache:
    untracked: true
    paths:
    - binaries/

使用任務中的緩存重寫全局設置，下面的rspec任務只會緩存binaries文件夾

cache:
  paths:
  - my/files

rspec:
  script: test
  cache:
    key: rspec
    paths:
    - binaries/

---

注意，當緩存被任務共享的時候，若是你在不一樣任務裏用了不一樣路徑，你須要設置一個不一樣的緩存鍵值，防止緩存內容被覆蓋。

緩存嗯，通過了優化，因此請不要指望緩存一直存在。更加詳細的緩存實現細節，請查看GitLabRunner

cache:key

自GitLab RunnerV1.0.0被引入

---

key指令容許用戶定義緩存的親和性（做用域？實驗過基本就是指緩存所做用的區域），key值定義的位置，可讓單個緩存適應全部的任務，也可讓單個緩存適應每個任務，也可讓單個緩存適應每個分支，或者是任何地方，你以爲合適的。

cache:key變量可使用任何runner預約義的變量

從GitLab9.0開始，key的默認值是默認爲整個項目，所以在默認下，全部的緩存都會被全部pipline和job共享~

注意：cache:key變量不能包含/字符

配置示例

容許job共用緩存（通過測試，若是key名稱設置爲job，那麼不一樣分支不一樣job都適用該cache策略）

cache:
  key: "$CI_JOB_NAME"
  untracked: true

容許每一個分支共用緩存(相同分支使用同一份緩存,實驗經過):

cache:
  key: "$CI_COMMIT_REF_NAME"
  untracked: true

容許每一個分支的每一個任務共用緩存：

cache:
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
  untracked: true

容許每一個分支的每一個階段共用緩存

cache:
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
  untracked: true

window下請用%替換￥，powershell下用$env:替換$

cache:policy

gitlab9.4引入

該項是指，一個緩存任務在執行開始前按計劃下載文件的默認行爲，在執行結束後按計劃從新上傳。這個選項容許job中形成的改變持久化，並被運用於後來的運行中。因此該項被譽爲pull-push的緩存策略。（沒試過，不造是啥）

若是你清楚的知道,你所執行的job不會修改已經緩存的文件夾，你能夠經過在job中聲明policy:pull設置跳過緩存上傳過程。（一般,該設置將伴隨着一個在早期作了普通緩存工做的job,以確保緩存存在，並有效）

stages:
  - setup
  - test

prepare:
  stage: setup
  cache:
    key: gems
    paths:
      - vendor/bundle
  script:
    - bundle install --deployment

rspec:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - bundle exec rspec ...

這樣的設置會加速job執行速度，而且減小向緩存服務器的請求，特別是當你有大量緩存任務並行執行的時候。

此外，若是你有一個job無條件性的從新創造了一個沒有前文引用的緩存，你能夠在job中使用policy: push 去跳過下載階段

gitlab-ci配置詳解(一)
gitlab-ci配置詳解(二)

資料

centos7簡單安裝gitlab-ce/ee(官網quick start)
GitLab簡明安裝指南
GitLab設置stmp發件
postfix mail command not find
gitLab修改默認端口
GitLab使用已有的nginx服務
GitLab-CI與GitLab-Runner
GitLab-Runner官方文檔
基於Gitlab CI搭建持續集成環境
如何漢化GitLab
非GitLab集成包手裝GitLab
GitLab從安裝到差點放棄