.gitlab-ci.yml文法

.gitlab-ci.yml

.gitlab-ci.yml 用來配置 CI 用你的項目中做哪些操作，這個檔案位于倉庫的根目錄。

當有新内容 push 到倉庫，或者有代碼合并後， GitLab 會查找是否有 .gitlab-ci.yml 檔案，如果檔案存在， Runners 将會根據該檔案的内容開始 build 本次 commit 。

.gitlab-ci.yml 使用 YAML 文法， 你需要格外注意縮進格式，要用空格來縮進，不能用 tabs 來縮進。

Stages

Stages 表示建構階段，說白了就是上面提到的流程。預設有3個 stages ： build , test , deploy 。我們可以在一次 Pipeline 中定義多個 Stages ，這些 Stages 會有以下特點：

1. 所有 Stages 會按照順序運作，即當一個 Stage 完成後，下一個 Stage 才會開始
2. 隻有當所有 Stages 完成後，該建構任務 (Pipeline) 才會成功
3. 如果任何一個 Stage 失敗，那麼後面的 Stages 不會執行，該建構任務 (Pipeline) 失敗

Jobs

Jobs 表示建構工作，表示某個 Stage 裡面執行的工作。我們可以在 Stages 裡面定義多個 Jobs ，這些 Jobs 會有以下特點：

1、相同 Stage 中的 Jobs 會并行執行

2、相同 Stage 中的 Jobs 都執行成功時，該 Stage 才會成功

3、如果任何一個 Job 失敗，那麼該 Stage 失敗，即該建構任務 (Pipeline) 失敗

限制

任務中必須得有 script 部分。

示例

# 定義 stages（階段）。任務将按此順序執行。

stages:

- build

- test

- deploy

# 定義 job（任務）

job1:

  stage: test

  tags:

  - XX #隻有标簽為XX的runner才會執行這個任務

  only:

  - dev #隻有dev分支送出代碼才會執行這個任務。也可以是分支名稱或觸發器名稱

  - /^future-.*$/ #正規表達式，隻有future-開頭的分支才會執行

  script:

  - echo "I am job1"

  - echo "I am in test stage"

# 定義 job

job2:

  stage: test #如果此處沒有定義stage，其預設也是test

  - master #隻有master分支送出代碼才會執行這個任務

  - echo "I am job2"

  allow_failure: true #允許失敗，即不影響下步建構

job3:

  stage: build

  except:

  - dev #除了dev分支，其它分支送出代碼都會執行這個任務

  - echo "I am job3"

  - echo "I am in build stage"

.job4: #對于臨時不想執行的job，可以選擇在前面加個"."，這樣就會跳過此步任務，否則你除了要注釋掉這個job4外，還需要注釋上面為deploy的stage

    stage: deploy

    script:

    - echo "I am job4"

# 模闆，相當于公用函數，有重複任務時很有用

.job_template: &job_definition # 建立一個錨，'job_definition'

  image: ruby:2.1

  services:

  - postgres

  - redis

test1:

  <<: *job_definition # 利用錨'job_definition'來合并

  - test1 project

test2:

  - test2 project

#下面幾個都相當于全局變量，都可以添加到具體job中，這時會被子job的覆寫

before_script:

- echo "每個job之前都會執行"

- export MVN_HOME

- export JAVA_HOME

- java -version

- sh /home/gitlab-runner/kill.sh

after_script:

- echo "每個job之後都會執行"

variables: #變量

  DATABASE_URL: "postgres://postgres@postgres/my_database" #在job中可以用${DATABASE_URL}來使用這個變量。常用的預定義變量有CI_COMMIT_REF_NAME（項目所在的分支或标簽名稱），CI_JOB_NAME（任務名稱），          CI_JOB_STAGE（任務階段）

  GIT_STRATEGY: "none" #GIT政策，定義拉取代碼的方式，有3種：clone/fetch/none，預設為clone，速度最慢，每步job都會重新clone一次代碼。我們一般将它設定為none，在具體任務裡設定為fetch就可以滿足需求，畢竟不是每步都需要新代碼，那也不符合我們測試的流程

cache: #緩存

  #因為緩存為不同管道和任務間共享，可能會覆寫，是以有時需要設定key

  key: ${CI_COMMIT_REF_NAME} # 啟用每分支緩存。

  #key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME" # 啟用每個任務和每個分支緩存。需要注意的是，如果是在windows中運作這個腳本，需要把$換成%

  untracked: true #緩存所有Git未跟蹤的檔案

  paths: #以下2個檔案夾會被緩存起來，下次建構會解壓出來

  - node_modules/

  - dist/

跳過job

如果你的 commit 資訊包涵 [ci skip] 或者 [skip ci] ，不論大小寫，這個 commit 将會被建立，但是 job 會被跳過

版本復原

-  build

-  deploy

build_job:

  tags: 

  - test1

  - echo "this is a test !"

dev_job:

  stage: deploy

  environment: 

    name: v2

    url:  http://www.test.com

  - echo "this is a deploy !"

environment: 是配置在deploy這個stage裡面的，用于後面Environments可以做版本復原。

紅色部分是URL，復原的時候點選即可直接跳轉到指定位置。

手動執行部署

    url:  www.baidu.com

  when: always #不管前面幾步成功與否，永遠會執行這一步。它有幾個值：on_success （預設值）\on_failure\always\manual（手動執行）

每次送出代碼就會自動觸發建構并自動釋出，production的建構釋出需要手動點選按鈕，這個是when: manual實作的。

when 用于實作在出現故障或運作失敗時運作的作業。

when 可以設定為以下值之一：

on_success - 隻有目前一個階段的所有工作成功時才執行工作。這是預設值。

on_failure - 僅目前一個階段的至少一個作業發生故障時才執行作業。

always - 無論前一階段的工作狀況如何，繼續執行工作。

manual - 手動執行作業（在GitLab 8.10中添加）

Docker Executor

所有jobs的執行環境為指定的docker image所生成的container，每個job都會生成一個container并且在job結束後立即銷毀。

Pull policies

當你使用docker 或 docker+machine executors時，你可以通過設定pull_policy來決定Runner如何pull docker image。pull_policy有三種值：

always —— Runner始終從遠端pull docker image。

if-not-present —— Runner會首先檢查本地是否有該image，如果有則用本地的，如果沒有則從遠端拉取。

never —— Runner始終使用本地的image。