摘要：因為可以安裝到不同的機器上，所以在構(gòu)建任務(wù)運行期間并不會影響到的性能。注冊打開中的項目頁面，在項目設(shè)置中找到在運行的機器上，用命令行注冊，比如按照提示一步一步安裝就可以了。任務(wù)將按此順序執(zhí)行。當(dāng)然，這是不符合語義的。

在介紹.gitlab-ci.yml之前，我們先看幾個概念：

一般來說，構(gòu)建任務(wù)都會占用很多的系統(tǒng)資源 (譬如編譯代碼)，而 GitLab CI 又是 GitLab 的一部分，如果由 GitLab CI 來運行構(gòu)建任務(wù)的話，在執(zhí)行構(gòu)建任務(wù)的時候，GitLab 的性能會大幅下降。

GitLab CI 最大的作用是管理各個項目的構(gòu)建狀態(tài)，因此，運行構(gòu)建任務(wù)這種浪費資源的事情就交給 GitLab Runner 來做啦。因為 GitLab Runner 可以安裝到不同的機器上，所以在構(gòu)建任務(wù)運行期間并不會影響到 GitLab 的性能。

GitLab Runner的安裝特別簡單，官網(wǎng)有各平臺的安裝方法或安裝包，此處不再贅述。

打開GitLab 中的項目頁面，在項目設(shè)置中找到 runners

在runner運行的機器上，用命令行注冊，比如：

gitlab-runner register --name="XX" --url="https://git.xx.com/" --token="XXX" --executor="shell"

按照提示一步一步安裝就可以了。其中，executor可以是多種類型，簡單的話可以選shell。有熟悉docker的可以使用docker。

配置文件在/etc/gitlab-runner/config.toml

配置項類似下面，可能需要手動添加builds_dir和cache_dir這兩個變量，再重啟服務(wù)

 [[runners]]
   name = "216XX"
   url = "https://git.XX.com/"
   token = "XX"
   executor = "shell"
   builds_dir = "/home/gitlab-runner/builds"
   cache_dir = "/home/gitlab-runner/cache"
   [runners.cache]

    sudo gitlab-runner list 查看各個 Runner 的狀態(tài)
    sudo gitlab-runner stop 停止服務(wù)
    sudo gitlab-runner start 啟動服務(wù)
    sudo gitlab-runner restart 重啟服務(wù)

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

所有 Stages 會按照順序運行，即當(dāng)一個 Stage 完成后，下一個 Stage 才會開始

只有當(dāng)所有 Stages 完成后，該構(gòu)建任務(wù) (Pipeline) 才會成功

如果任何一個 Stage 失敗，那么后面的 Stages 不會執(zhí)行，該構(gòu)建任務(wù) (Pipeline) 失敗

Jobs 表示構(gòu)建工作，表示某個 Stage 里面執(zhí)行的工作。我們可以在 Stages 里面定義多個 Jobs，這些 Jobs 會有以下特點：

1、相同 Stage 中的 Jobs 會并行執(zhí)行

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

3、如果任何一個 Job 失敗，那么該 Stage 失敗，即該構(gòu)建任務(wù) (Pipeline) 失敗

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

當(dāng)有新內(nèi)容push到倉庫，或者有代碼合并后，GitLab會查找是否有.gitlab-ci.yml文件，如果文件存在，Runners將會根據(jù)該文件的內(nèi)容開始build本次commit。

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

任務(wù)中必須得有script部分。

# 定義 stages（階段）。任務(wù)將按此順序執(zhí)行。
stages:
  - build
  - test
  - deploy

# 定義 job（任務(wù)）
job1:
  stage: test
  tags:
    - XX #只有標(biāo)簽為XX的runner才會執(zhí)行這個任務(wù)
  only:        
    - dev    #只有dev分支提交代碼才會執(zhí)行這個任務(wù)。也可以是分支名稱或觸發(fā)器名稱
    - /^future-.*$/ #正則表達式，只有future-開頭的分支才會執(zhí)行
  script:
    - echo "I am job1"
    - echo "I am in test stage"

# 定義 job
job2:
  stage: test    #如果此處沒有定義stage，其默認(rèn)也是test
  only:
    - master    #只有master分支提交代碼才會執(zhí)行這個任務(wù)
  script:
    - echo "I am job2"
    - echo "I am in test stage"
  allow_failure: true #允許失敗，即不影響下步構(gòu)建    

# 定義 job
job3:
  stage: build
  except:    
    - dev #除了dev分支，其它分支提交代碼都會執(zhí)行這個任務(wù)
  script:
    - echo "I am job3"
    - echo "I am in build stage"    
  when: always #不管前面幾步成功與否，永遠會執(zhí)行這一步。它有幾個值：on_success （默認(rèn)值）on_failurealwaysmanual（手動執(zhí)行）
    
# 定義 job
.job4:    #對于臨時不想執(zhí)行的job，可以選擇在前面加個"."，這樣就會跳過此步任務(wù)，否則你除了要注釋掉這個jobj外，還需要注釋上面為deploy的stage
  stage: deploy
  script:
    - echo "I am job4"    

# 模板，相當(dāng)于公用函數(shù)，有重復(fù)任務(wù)時很有用
.job_template: &job_definition  # 創(chuàng)建一個錨，"job_definition"
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  <<: *job_definition           # 利用錨"job_definition"來合并
  script:
    - test1 project

test2:
  <<: *job_definition           # 利用錨"job_definition"來合并
  script:
    - test2 project    

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

before_script:
  - echo "每個job之前都會執(zhí)行"    
  
after_script:
  - echo "每個job之后都會執(zhí)行"    
  
variables:    #變量
  DATABASE_URL: "postgres://postgres@postgres/my_database"  #在job中可以用${DATABASE_URL}來使用這個變量。常用的預(yù)定義變量有CI_COMMIT_REF_NAME（項目所在的分支或標(biāo)簽名稱），CI_JOB_NAME（任務(wù)名稱），CI_JOB_STAGE（任務(wù)階段）
  GIT_STRATEGY: "none" #GIT策略，定義拉取代碼的方式，有3種：clone/fetch/none，默認(rèn)為clone，速度最慢，每步j(luò)ob都會重新clone一次代碼。我們一般將它設(shè)置為none，在具體任務(wù)里設(shè)置為fetch就可以滿足需求，畢竟不是每步都需要新代碼，那也不符合我們測試的流程

cache:    #緩存
  #因為緩存為不同管道和任務(wù)間共享，可能會覆蓋，所以有時需要設(shè)置key
  key: ${CI_COMMIT_REF_NAME}  # 啟用每分支緩存。
  #key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME" # 啟用每個任務(wù)和每個分支緩存。需要注意的是，如果是在windows中運行這個腳本，需要把$換成%
  untracked: true    #緩存所有Git未跟蹤的文件
  paths:    #以下2個文件夾會被緩存起來，下次構(gòu)建會解壓出來
    - node_modules/
    - dist/  

https://git.xx.com/ci/lint

如果你的commit信息包涵[ci skip]或者[skip ci]，不論大小寫，這個commit將會被創(chuàng)建，但是job會被跳過

使用shell腳本時，每步job一開始總有不短的等待時間，對于我們而言是不必要的，除去后臺jenkins_build這步外，仍要最快20分鐘。

之前，我曾在release分支時，暫時將各步整合到一個job里，時間縮短為5分鐘。當(dāng)然，這是不符合語義的。

最近，發(fā)現(xiàn)docker沒有這個問題。所以，建議使用docker。

以下是我們項目中使用的.gitlab-ci.yml文件:

image: xx:1.0

stages:
  - jenkins_build
  - install
  - test
  - build
  - e2e
  - zip
  - copy
  - end

cache:
    policy: pull
    key: "$CI_COMMIT_REF_NAME"
    paths:
        - node_modules/
        - .eslintcache

variables:
  DOCKER_DRIVER: overlay2
  GIT_STRATEGY: "fetch"

.template: &templateDef  # 創(chuàng)建一個錨，"template"
  only:
      - master
      - release
      - dev

install:
  stage: install
  <<: *templateDef           # 利用錨"templateDef"來合并
  cache:
      key: "$CI_COMMIT_REF_NAME"
      paths:
          - node_modules
  script:
    - cnpm i

eslint:
  stage: test
  <<: *templateDef
  script:
    - npm run eslint

unit:
  stage: test
  <<: *templateDef
  script:
    - npm run unit

build:
  stage: build
  <<: *templateDef
  only:
      - release
  script:
    - npm run clear_dist
    - npm run build

.e2e_ci:
  stage: e2e
  <<: *templateDef
  script:
    - npm run e2e_ci

zip:
  stage: zip
  <<: *templateDef
  only:
      - release
  script:
    - npm run zip

## Jenkins 復(fù)制
jenkins_copyweb:
  stage: copy
  <<: *templateDef
  only:
      - release
  script:
    - ssh $JENKINS_SERVER_IP /jenkins/XX_copyweb.sh

## Jenkins 提交
jenkins_commit:
  stage: end
  <<: *templateDef
  only:
      - release
  script:
    - ssh $JENKINS_SERVER_IP /jenkins/XX_svn_commit.sh

## Jenkins 構(gòu)建
jenkins_build:
  stage: jenkins_build
  <<: *templateDef
  only:
      - master
  script:
     - ssh $JENKINS_SERVER_IP /jenkins/build.sh

其中，XX:1.0是我們自己創(chuàng)建的docker鏡像，它主要安裝了nodejs、cnpm、jdk、sshpass，其中sshpass不是必須的，它是使用密碼登陸宿主機時的一種方案。

現(xiàn)在，我們使用ssh來與宿主機交互，需要將容器內(nèi)生成的ssh的key（ssh-keygen -t rsa），即/root/.ssh/id_rsa.pub中內(nèi)容，復(fù)制到宿主機的/root/.ssh/authorized_keys文件中。

配置文件/etc/gitlab-runner/config.toml修改為

[[runners]]
  name = "216xx"
  url = "https://git.xx.com/"
  token = "xx"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "xx:1.0"
    privileged = false
    disable_cache = false
    pull_policy = "if-not-present"
    volumes = ["/cache","/tmp:/tmp:rw"]
    shm_size = 0
  [runners.cache]

其中，pull_policy是下載docker鏡像image的策略，默認(rèn)會先從網(wǎng)上找，沒有就報錯，我們改為先從本地找；volumes是將docker中的數(shù)據(jù)卷掛載到宿主機上。