云原生專欄大綱

gitlab-ci.yml 介紹

gitlab-ci.yml 是 GitLab CI/CD 的配置文件，用于定義項(xiàng)目的持續(xù)集成和持續(xù)交付流程。它采用 YAML 格式，位于項(xiàng)目的根目錄或指定的目錄中。
gitlab-ci.yml 文件包含了一系列的作業(yè)（jobs）和階段（stages），定義了項(xiàng)目在不同情況下的構(gòu)建、測(cè)試、部署等操作。以下是一些常見的 gitlab-ci.yml 配置項(xiàng)：

• image：指定用于作業(yè)執(zhí)行的 Docker 鏡像?？梢赃x擇現(xiàn)有的鏡像，也可以自定義鏡像。
• stages：定義項(xiàng)目的階段順序。每個(gè)階段包含一組作業(yè)。
• before_script：在每個(gè)作業(yè)執(zhí)行之前運(yùn)行的腳本命令?？梢杂糜谠O(shè)置環(huán)境、安裝依賴等操作。
• after_script：在每個(gè)作業(yè)執(zhí)行之后運(yùn)行的腳本命令。可以用于清理環(huán)境、收集結(jié)果等操作。
• variables：定義作業(yè)的環(huán)境變量?？梢栽谧鳂I(yè)的腳本中使用這些變量。
• jobs：定義項(xiàng)目的作業(yè)。每個(gè)作業(yè)包含一個(gè)或多個(gè)腳本命令，用于執(zhí)行具體的操作。
  • script：指定作業(yè)要執(zhí)行的腳本命令?？梢允菃蝹€(gè)命令或多個(gè)命令的序列。
  • artifacts：定義作業(yè)產(chǎn)生的構(gòu)建產(chǎn)物，可以在后續(xù)的作業(yè)中使用。
  • only 和 except：指定作業(yè)執(zhí)行的條件。可以基于分支、標(biāo)簽、變量等進(jìn)行條件判斷。

gitlab-ci.yml 文件的配置可以根據(jù)項(xiàng)目的需求進(jìn)行自定義。你可以定義多個(gè)作業(yè)和階段，根據(jù)需要設(shè)置依賴關(guān)系，以及在不同的條件下執(zhí)行不同的操作。這使得你能夠構(gòu)建靈活、可擴(kuò)展的 CI/CD 流程，提高開發(fā)效率和軟件質(zhì)量。

需要注意的是，一旦 gitlab-ci.yml 文件發(fā)生變化，GitLab 會(huì)自動(dòng)檢測(cè)并開始執(zhí)行新的 CI/CD 流程。執(zhí)行結(jié)果和日志可以在 GitLab 的界面中查看和分析。

GitLab中語法檢測(cè)

1. 進(jìn)入CI/CD->配置檢查

2. 語法檢測(cè)（這兒可以像寫代碼一樣測(cè)試腳本）

gitlab-ci.yml 語法

官網(wǎng)gitlab-ci.yml語法，官網(wǎng)在線文檔維護(hù)的最低版本是14.10，若想看更低版本文GitLab Docs歷史版本。GitLabPipeline語法。

# 較老版本
docker run -it --rm -p 4000:4000 registry.gitlab.com/gitlab-org/gitlab-docs:11.1
# 較新版本
docker run -it --rm -p 4000:4000 registry.gitlab.com/gitlab-org/gitlab-docs/archives:15.5

docker run -it --rm -p 4000:4000 registry.gitlab.com/gitlab-org/gitlab-docs:11.1

GitLab CI/CD 示例：http://localhost:4000/11.1/ee/ci/examples/README.html
gitlab-ci.yml 語法參考：http://localhost:4000/11.1/ee/ci/yaml/README.html

常用關(guān)鍵字：

job/script/before_script/after_script/stages/stage/variables/tags/allow_failure/when/retry/timeout/parallel

job無標(biāo)簽，runner有標(biāo)簽，流水線job被卡住情況：

登錄gitlab修改runner配置勾選運(yùn)行沒有標(biāo)簽的作業(yè)：

job定義作業(yè)

job至少包含一個(gè)script

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

job2:
  script: 
    - uname -a
    - bundle exec respec

注意:有時(shí), script命令將需要用單引號(hào)或雙引號(hào)引起來.例如,包含冒號(hào)命令(:)需要加引號(hào),以便被包裹的YAML解析器知道來解釋整個(gè)事情作為一個(gè)字符串，而不是一個(gè)"鍵：值"對(duì).使用特殊字符時(shí)要小心：},[,],&,*,#,?,1,-,<,>,=!,8,@,

job下能使用的參數(shù)關(guān)鍵字：

before_script和after_script

before_script用于定義應(yīng)先運(yùn)行的命令 作業(yè)，包括部署作業(yè)，但在還原項(xiàng)目之后。 這可以是數(shù)組或多行字符串。
after_script用于定義將在 all 之后運(yùn)行的命令 作業(yè)，包括失敗的作業(yè)。這必須是數(shù)組或多行字符串。

before_script:
  - echo "global before script... "
after_script:
  - echo "global before after_script... "

stages:
  - job1
  - job2

job1:
  stage: job1
  before_script:
    - echo "job1 before_script... "
  script:
    - echo "job1 script... "
  after_script:
    - echo "job1 after_script... "
job2:
  stage: job2
  script:
    - echo "job2 script... "

before_script失敗導(dǎo)致整個(gè)作業(yè)失敗，其他作業(yè)將不再執(zhí)行。作業(yè)失敗不會(huì)影響after_script運(yùn)行。

job1運(yùn)行日志：沒有執(zhí)行全局before_script和after_script

job2運(yùn)行日志：執(zhí)行全局before_script和after_script

stages定義階段

stages全局定義階段執(zhí)行順序；stages在job中定義，指定job在那個(gè)階段。

1. 同一階段的作業(yè)并行運(yùn)行。
2. 下一階段的作業(yè)在上一階段的作業(yè)之后運(yùn)行 成功完成。

before_script:
  - echo "global before script... "
after_script:
  - echo "global before after_script... "

# 全局定義階段執(zhí)行順序
stages:
  - build
  - test
  - deploy

job1:
  stage: build
  before_script:
    - echo "job1 before_script... "
  script:
    - echo "job1 script... "
  after_script:
    - echo "job1 after_script... "
job2:
  stage: test
  script:
    - echo "job2 script... "

job3:
  stage: test
  script:
    - echo "job3 script... "

job4:
  stage: deploy
  script:
    - echo "job3 script... "

job2和job3在同一stage，作業(yè)并行執(zhí)行

并行需要修改gitlab-runner中 /etc/gitlab-runner/config.toml下concurrent并發(fā)數(shù)配置，該配置默認(rèn)1。修改后自動(dòng)生效。

3. .pre和.post

.pre：在流水線運(yùn)行之前運(yùn)行； .post： 在流水線運(yùn)行之后運(yùn)行

pre:
  stage: .pre
  script:
    - echo "pre script... "
post:
  stage: .post
  script:
    - echo "post script... "

tages指定runner

用于指定job在那個(gè)runner上執(zhí)行

stages:
  - build
  - deploy

build_job:
  stage: build
  tags:
    - build
  only: 
    - master
  script:
    - echo "Building the project... "


deploy_job:
  stage: deploy
  tags:
    - deploy
  only:
    - master
  script:
    - echo "Deploying the project..."

查看build和deploy作業(yè)日志驗(yàn)證是否在指定runner上運(yùn)行
build_job日志：runner使用的3a8211f3

deploy_job日志：runner使用的c62726d6

跟下述創(chuàng)建的runner令牌能對(duì)應(yīng)上

allow_failure運(yùn)行失敗

allow_failure允許作業(yè)失敗，默認(rèn)值為false。啟用后，如果作業(yè)失敗，該作業(yè)將在用戶界面中顯示橙色警告。但是，管道的邏輯流程將認(rèn)為作業(yè)成功/通過，并且不會(huì)被阻塞。假設(shè)所有其他作業(yè)均成功，則該作業(yè)的階段及其管道將顯示相同的橙色警告。但是，關(guān)聯(lián)的提交將被標(biāo)記為"通過"，而不會(huì)發(fā)出警告。

下述job2中script下腳本寫錯(cuò)模擬失敗情況：

before_script:
  - echo "global before script... "
after_script:
  - echo "global before after_script... "

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  before_script:
    - echo "job1 before_script... "
  script:
    - echo "job1 script... "
  after_script:
    - echo "job1 after_script... "
job2:
  stage: test
  script:
    - ech "job2 script... "
  allow_failure: true

job3:
  stage: test
  script:
    - echo "job3 script... "

job4:
  stage: deploy
  script:
    - echo "job3 script... "

when控制作業(yè)運(yùn)行

• on_success（默認(rèn)）：之前所有job執(zhí)行成功，才執(zhí)行，否則跳過執(zhí)行
• on_failure：之前有job執(zhí)行失敗，才執(zhí)行
• never：無論作業(yè)在早期階段的狀態(tài)如何，都不要運(yùn)行作業(yè)。
• always：無論作業(yè)在早期階段的狀態(tài)如何，都運(yùn)行作業(yè)。
• manual：僅在手動(dòng)觸發(fā)時(shí)運(yùn)行作業(yè)。
• delayed：將作業(yè)的執(zhí)行延遲到指定的持續(xù)時(shí)間。

stages:
  - build
  - test
  - deploy


job_ok:
  stage: build
  script:
    - echo "job_ok... "

on_failure_job_skip:
  stage: test
  script:
    - echo "on_failure_job_skip... "
  when: on_failure

on_success_job_run:
  stage: test
  script:
    - echo "on_success_job_run... "
  when: on_success

job_err:
  stage: test
  script:
    - ech "on_success_job_run... "


on_failure_job_run:
  stage: deploy
  script:
    - echo "on_failure_job_run... "
  when: on_failure

注意當(dāng)錯(cuò)誤執(zhí)行使用allow_failure: true，stage會(huì)認(rèn)為是正確，驗(yàn)證如下on_failure_job_run沒執(zhí)行

retry重試

配置在失敗的情況下重試作業(yè)的次數(shù)。重試成功或達(dá)到最大重試次數(shù)就在執(zhí)行該job

job_err:
  stage: test
  script:
    - ech "on_success_job_run... "
 # retry: 2 # 11.1.4版本使用該語法，還不支持when
  retry:
    max: 2
    when:
    - script_failure

重試錯(cuò)誤類型

always ：在發(fā)生任何故障時(shí)重試（默認(rèn)）.
unknown_failure ：當(dāng)失敗原因未知時(shí)。
script_failure ：腳本失敗時(shí)重試。
api_failure ：API失敗重試。
stuck_or_timeout_failure ：作業(yè)卡住或超時(shí)時(shí)。
runner_system_failure ：運(yùn)行系統(tǒng)發(fā)生故障。
missing_dependency_failure: 如果依賴丟失。
runner_unsupported ：Runner不受支持。
stale_schedule ：無法執(zhí)行延遲的作業(yè)。
job_execution_timeout ：腳本超出了為作業(yè)設(shè)置的最大執(zhí)行時(shí)間。
archived_failure ：作業(yè)已存檔且無法運(yùn)行。
unmet_prerequisites ：作業(yè)未能完成先決條件任務(wù)。
scheduler_failure ：調(diào)度程序未能將作業(yè)分配給運(yùn)行scheduler_failure。
data_integrity_failure ：檢測(cè)到結(jié)構(gòu)完整性問題。

timeout超時(shí)

作業(yè)級(jí)別超時(shí)配置：

job_ok:
  stage: build
  script:
    - echo "job_ok... "
  timeout: 3h 30m  # 作業(yè)級(jí)別超時(shí)

作業(yè)級(jí)別的超時(shí)可以超過項(xiàng)目級(jí)別超時(shí)，但不能超過Runner特定的超時(shí)。

項(xiàng)目超時(shí)時(shí)間配置如下：

runner超時(shí)配置：

如果小于項(xiàng)目定義超時(shí)時(shí)間將具有優(yōu)先權(quán)。此功能可用于通過設(shè)置大超時(shí)（例如一個(gè)星期）來防止SharedRunner被項(xiàng)目占用。未配置時(shí)，Runner將不會(huì)覆蓋項(xiàng)目超時(shí)。

超時(shí)時(shí)間到底哪個(gè)生效？

當(dāng)項(xiàng)目和runner都設(shè)置了超時(shí)時(shí)間，那個(gè)小那個(gè)生效。runner未設(shè)置，項(xiàng)目設(shè)置超時(shí)時(shí)間，項(xiàng)目設(shè)置生效。

parallel并行作業(yè)

用于在單個(gè)管道中并行多次運(yùn)行作業(yè)。在 GitLab 15.9 中引入，最大值從 50 增加到 200。

job_ok:
  stage: build
  script:
    - echo "job_ok... "
  parallel: 5

only & except

1. only定義哪些分支和標(biāo)簽的git項(xiàng)目將會(huì)被job執(zhí)行。
2. except定義哪些分支和標(biāo)簽的git項(xiàng)目將不會(huì)被job執(zhí)行。

注意：官網(wǎng)提示已廢棄，但還能使用。推薦使用rules代替。

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

rules

用于在管道中包含或排除作業(yè)。job中按順序執(zhí)行，直到匹配到

在 GitLab 12.3 中引入。請(qǐng)注意， rules不能與only/except組合使用。

匹配規(guī)則：下述規(guī)則可以嵌套使用

stages:
  - build
  - test
  - deploy

variables:
  NAME: gitlab

job_ok:
  stage: build
  script:
    - echo "job_ok... "

rules-if-true:
  stage: test
  script:
    - echo "rules-if-true... "
  rules:
    - if: $NAME == "gitlab"

rules-if-when-never:
  stage: test
  script:
    - echo "rules-if-when-never... "
  rules:
    - if: $NAME == "gitlab"
      when: never

rules-changes-true:
  stage: test
  script:
    - echo "rules-changes-true... "
  rules:
    - changes:
      - Jenkinsfile

rules-changes-false:
  stage: test
  script:
    - echo "rules-changes-false... "
  rules:
    - changes:
      - pom.xml
  allow_failure: true

on_success_job_run:
  stage: deploy
  script:
    - echo "on_success... "
  when: on_success

修改Jenkinsfile文件提交：rules-changes-false和rules-if-when-never沒有執(zhí)行

修改pom.xml提交：rules-changes-true和rules-if-when-never沒執(zhí)行

cache 緩存

在 GitLab 15.0 中引入，緩存不會(huì)在受保護(hù)和不受保護(hù)的分支之間共享。

用來指定需要在job之間緩存的文件或目錄。只能使用該項(xiàng)目工作空間內(nèi)的路徑（及gitlab-runner內(nèi)部緩存）。不要使用緩存在階段之間傳遞工件，因?yàn)榫彺嬷荚诖鎯?chǔ)編譯項(xiàng)目所需的運(yùn)行時(shí)依賴項(xiàng)。
如果在job范圍之外定義了cache ，則意味著它是全局設(shè)置，所有job都將使用該定義。如果未全局定義或未按job定義則禁用該功能。

cache:paths

使用paths指令選擇要緩存的文件或目錄，路徑是相對(duì)于項(xiàng)目目錄，不能直接鏈接到項(xiàng)目目錄之外。$CI_PROJECT_DIR 項(xiàng)目目錄
在job build中定義緩存，將會(huì)緩存target目錄下的所有.jar文件。

build:
  script: test
  cache:
    paths:
      - target/*.jar

當(dāng)在全局定義了cache:paths會(huì)被job中覆蓋。以下實(shí)例將緩存binaries目錄。

cache:
  paths:
    - my/files

build:
  script: echo "hello"
  cache:
    key: build
    paths:
      - target/

cache-job:
  stage: build
  script:
    - echo "job_ok... "
  cache:
    key: kustomize
    paths:
      - kustomize/

由于緩存是在job之間共享的，如果不同的job使用不同的路徑就出現(xiàn)了緩存覆蓋的問題。如何讓不同的job緩存不同的cache呢？設(shè)置不同的cache:key。

cache:key 緩存標(biāo)記

為緩存做個(gè)標(biāo)記，可以配置job、分支為key來實(shí)現(xiàn)分支、作業(yè)特定的緩存。為不同 job 定義了不同的 cache:key 時(shí)， 會(huì)為每個(gè) job 分配一個(gè)獨(dú)立的 cache。cache:key變量可以使用任何預(yù)定義變量，默認(rèn)default ，從GitLab 9.0開始，默認(rèn)情況下所有內(nèi)容都在管道和作業(yè)之間共享。
按照分支設(shè)置緩存

cache-job:
  stage: build
  script:
    - echo "job_ok... "
  cache:
    key: kustomize
    paths:
      - kustomize/

進(jìn)入gitlab-runner終端查看緩存：

cache??files

在 GitLab 12.5 中引入。

文件發(fā)生變化自動(dòng)重新生成緩存(files最多指定兩個(gè)文件)，提交的時(shí)候檢查指定的文件。
根據(jù)指定的文件生成密鑰計(jì)算SHA校驗(yàn)和，如果文件未改變值為default。

  cache:
    key:
      files:
        - pom.xml
    paths:
      - kustomize/

進(jìn)入gitlab-runner終端查看緩存：

cache??prefix

prefix: 允許給定prefix的值與指定文件生成的秘鑰組合。

  cache:
    key:
      files:
        - pom.xml
      prefix: $CI_JOB_NAME
    paths:
      - kustomize/

cache:policy 策略

默認(rèn)：在執(zhí)行開始時(shí)下載文件，并在結(jié)束時(shí)重新上傳文件。稱為pull-push緩存策略.
policy: pull ：將作業(yè)設(shè)置為僅在作業(yè)啟動(dòng)時(shí)下載緩存，但從不上傳更改
policy: push ： 將作業(yè)設(shè)置為僅在作業(yè)完成時(shí)上傳緩存，但從不下載 緩存

prepare-dependencies-job:
  stage: build
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: push
  script:
    - echo "This job only downloads dependencies and builds the cache."
    - echo "Downloading dependencies..."

faster-test-job:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - echo "This job script uses the cache, but does not update it."
    - echo "Running tests..."

artifacts

用于指定在作業(yè)成功或者失敗時(shí)應(yīng)附加到作業(yè)的文件或目錄的列表。作業(yè)完成后，工件將被發(fā)送到GitLab，并可在GitLab UI中下載。
在GitLab Runner中，Artifacts（構(gòu)件）是指在CI/CD流程中生成的文件或目錄，它們可以被傳遞、存儲(chǔ)和共享。Artifacts通常用于將構(gòu)建產(chǎn)物、測(cè)試報(bào)告、生成的文檔等相關(guān)文件保存下來，以便后續(xù)的步驟或階段可以使用或查看。
當(dāng)作業(yè)執(zhí)行完成后，你可以將指定的文件或目錄定義為Artifacts，并將其上傳到GitLab服務(wù)器上。這些Artifacts可以在GitLab界面中查看，并且可以被其他作業(yè)或階段使用。
Artifacts提供了以下優(yōu)點(diǎn)和用途：

1. 持久化構(gòu)建結(jié)果：通過將構(gòu)建產(chǎn)物定義為Artifacts，你可以將構(gòu)建生成的文件或目錄保留下來，即使作業(yè)執(zhí)行完畢后也可以隨時(shí)訪問。這對(duì)于構(gòu)建產(chǎn)物的后續(xù)使用或分析非常有用。
2. 共享和傳遞數(shù)據(jù)：Artifacts可以在不同的作業(yè)或階段之間傳遞數(shù)據(jù)。例如，一個(gè)作業(yè)可以生成一些文件，然后將這些文件定義為Artifacts，接下來的作業(yè)可以通過下載這些Artifacts來使用這些文件。
3. 查看和下載：通過GitLab界面，你可以方便地查看和下載Artifacts。這使得團(tuán)隊(duì)成員可以輕松訪問和檢查構(gòu)建結(jié)果、測(cè)試報(bào)告等。

cache-job:
  stage: build
  script:
    - echo "job_ok... "
  cache:
    key: kustomize
    paths:
      - kustomize/
  artifacts:
    paths:
      - kustomize/
    expose_as: gitlab-kustomize
    name: my-kustomize
    when: always
    expire_in: 1 week
    reports:
      junit: junit.xml 

上述示例中，job1作業(yè)在構(gòu)建過程中生成了一個(gè)build/目錄和一個(gè)test_results.xml文件。通過artifacts關(guān)鍵字，將這些構(gòu)建產(chǎn)物定義為Artifacts。在作業(yè)執(zhí)行完成后，這些Artifacts將被上傳到GitLab服務(wù)器上，并可以在后續(xù)的作業(yè)中使用或下載。
通過Artifacts，你可以方便地管理和共享CI/CD流程中的產(chǎn)物，提高團(tuán)隊(duì)的協(xié)作和效率。

查看下載壓縮包中內(nèi)容：下載壓縮包名my-kustomize.zip

gitlab中查看artifacts

禁用工件傳遞

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

您可能只想為標(biāo)記的發(fā)行版創(chuàng)建構(gòu)件，以避免用臨時(shí)構(gòu)建構(gòu)件填充構(gòu)建服務(wù)器存儲(chǔ)。僅為標(biāo)簽創(chuàng)建工件（ default-job不會(huì)創(chuàng)建工件）：

default-job:
  script:
    - mvn test -U
  except:
    - tags

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

needs 并行階段

可無序執(zhí)行作業(yè)，無需按照階段順序運(yùn)行某些作業(yè)，可以讓多個(gè)階段同時(shí)運(yùn)行。

stages:
  - build
  - test
  - deploy

module-a-build:
  stage: build
  script: 
    - echo "hello3a"
    - sleep 10
    
module-b-build:
  stage: build
  script: 
    - echo "hello3b"
    - sleep 10

module-a-test:
  stage: test
  script: 
    - echo "hello3a"
    - sleep 10
  needs: ["module-a-build"]
    
module-b-test:
  stage: test
  script: 
    - echo "hello3b"
    - sleep 10
  needs: ["module-b-build"]

如果needs:設(shè)置為指向因only/except規(guī)則而未實(shí)例化的作業(yè)，或者不存在，則創(chuàng)建管道時(shí)會(huì)出現(xiàn)YAML錯(cuò)誤。
暫時(shí)限制了作業(yè)在needs:可能需要的最大作業(yè)數(shù)分配,ci_dag_limit_needs功能標(biāo)志已啟用（默認(rèn)）分配10個(gè)，如果功能被禁用為50。

Feature::disable(:ci_dag_limit_needs)   # 50
Feature::enable(:ci_dag_limit_needs)  #10

制品下載

在使用needs，可通過artifacts: true或artifacts: false來控制工件下載。 默認(rèn)不指定為true。

module-a-test:
  stage: test
  script: 
    - echo "hello3a"
    - sleep 10
  needs: 
    - job: "module-a-build"
      artifacts: true

相同項(xiàng)目中的管道制品下載,通過將project關(guān)鍵字設(shè)置為當(dāng)前項(xiàng)目的名稱，并指定引用，可以使用needs從當(dāng)前項(xiàng)目的不同管道中下載工件。在下面的示例中，build_job將使用other-refref下載最新成功的build-1作業(yè)的工件：

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: group/same-project-name
      job: build-1
      ref: other-ref
      artifacts: true

不支持從parallel:運(yùn)行的作業(yè)中下載工件。

include

https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates
可以允許引入外部YAML文件，文件具有擴(kuò)展名.yml或.yaml 。使用合并功能可以自定義和覆蓋包含本地定義的CI / CD配置。相同的job會(huì)合并，參數(shù)值以源文件為準(zhǔn)。

local

引入同一存儲(chǔ)庫中的文件，使用相對(duì)于根目錄的完整路徑進(jìn)行引用，與配置文件在同一分支上使用。
ci/localci.yml: 定義一個(gè)作業(yè)用于發(fā)布。

stages:
  - deploy
  
deployjob:
  stage: deploy
  script:
    - echo 'deploy'

.gitlab-ci.yml 引入本地的CI文件’ci/localci.yml’。

include:
  local: 'ci/localci.yml'
  

stages:
  - build
  - test
  - deploy
  

buildjob:
  stage: build
  script: ls
  
 
testjob:
  stage: test
  script: ls

效果

file

包含來自另一個(gè)項(xiàng)目的文件

include:
  - project: demo/demo-java-service
    ref: master
    file: '.gitlab-ci.yml'

template

只能使用官方提供的模板 https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates

include:
  - template: Auto-DevOps.gitlab-ci.yml

remote

用于通過HTTP / HTTPS包含來自其他位置的文件，并使用完整URL進(jìn)行引用. 遠(yuǎn)程文件必須可以通過簡(jiǎn)單的GET請(qǐng)求公開訪問，因?yàn)椴恢С诌h(yuǎn)程URL中的身份驗(yàn)證架構(gòu)。

include:
  - remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'

extends

繼承模板作業(yè)

stages:
  - test
variables:
  RSPEC: 'test'

.tests:
  script: echo "mvn test"
  stage: test
  only:
    refs:
      - branches

testjob:
  extends: .tests
  script: echo "mvn clean test"
  only:
    variables:
      - $RSPEC

合并后

testjob:
  stage: test
  script: mvn clean test
  only:
    variables:
      - $RSPEC
    refs:
      - branches

extends & include

aa.yml

#stages:
#  - deploy
  
deployjob:
  stage: deploy
  script:
    - echo 'deploy'
  only:
    - dev

.template:
  stage: build
  script: 
    - echo "build"
  only:
    - master

include:
  local: 'ci/localci.yml'

stages:
  - test
  - build 
  - deploy
  
variables:
  RSPEC: 'test'

.tests:
  script: echo "mvn test"
  stage: test
  only:
    refs:
      - branches

testjob:
  extends: .tests
  script: echo "mvn clean test"
  only:
    variables:
      - $RSPEC
      

newbuildjob:
  script:
    - echo "123"
  extends: .template

這將運(yùn)行名為useTemplate的作業(yè)，該作業(yè)運(yùn)行echo Hello! 如.template作業(yè)中所定義，并使用本地作業(yè)中所定義的alpine Docker映像.

trigger 管道觸發(fā)

在GitLab Runner中，trigger關(guān)鍵字用于觸發(fā)另一個(gè)項(xiàng)目的CI/CD流程。通過使用trigger，你可以在一個(gè)項(xiàng)目的CI/CD流程中觸發(fā)另一個(gè)項(xiàng)目的流程，實(shí)現(xiàn)項(xiàng)目間的集成和協(xié)作。允許創(chuàng)建多項(xiàng)目管道和子管道。將trigger與when:manual一起使用會(huì)導(dǎo)致錯(cuò)誤。
多項(xiàng)目管道： 跨多個(gè)項(xiàng)目設(shè)置流水線，以便一個(gè)項(xiàng)目中的管道可以觸發(fā)另一個(gè)項(xiàng)目中的管道。[微服務(wù)架構(gòu)]
父子管道: 在同一項(xiàng)目中管道可以觸發(fā)一組同時(shí)運(yùn)行的子管道,子管道仍然按照階段順序執(zhí)行其每個(gè)作業(yè)，但是可以自由地繼續(xù)執(zhí)行各個(gè)階段，而不必等待父管道中無關(guān)的作業(yè)完成。

多項(xiàng)目管道

當(dāng)前面階段運(yùn)行完成后，觸發(fā)demo/demo-java-service項(xiàng)目master流水線。創(chuàng)建上游管道的用戶需要具有對(duì)下游項(xiàng)目的訪問權(quán)限。如果發(fā)現(xiàn)下游項(xiàng)目用戶沒有訪問權(quán)限以在其中創(chuàng)建管道，則staging作業(yè)將被標(biāo)記為_失敗_。

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: 
    project: demo/demo-java-service
    branch: master
    strategy: depend

project關(guān)鍵字，用于指定下游項(xiàng)目的完整路徑。該branch關(guān)鍵字指定由指定的項(xiàng)目分支的名稱。使用variables關(guān)鍵字將變量傳遞到下游管道。 全局變量也會(huì)傳遞給下游項(xiàng)目。上游管道優(yōu)先于下游管道。如果在上游和下游項(xiàng)目中定義了兩個(gè)具有相同名稱的變量，則在上游項(xiàng)目中定義的變量將優(yōu)先。默認(rèn)情況下，一旦創(chuàng)建下游管道，trigger作業(yè)就會(huì)以success狀態(tài)完成。strategy: depend將自身狀態(tài)從觸發(fā)的管道合并到源作業(yè)。

在下游項(xiàng)目中查看管道信息

在此示例中，一旦創(chuàng)建了下游管道，該staging將被標(biāo)記為成功。

父子管道

創(chuàng)建子管道ci/child01.yml

stages:
  - build

child-a-build:
  stage: build
  script: 
    - echo "hello3a"
    - sleep 10

在父管道觸發(fā)子管道

staging2:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: 
    include: ci/child01.yml  
    strategy: depend

image

注意：使用docker類型執(zhí)行器，只要使用執(zhí)行器為docker類型的runner所有的操作運(yùn)行都會(huì)在容器中運(yùn)行。

mage關(guān)鍵字用于指定在CI/CD作業(yè)中使用的Docker鏡像。通過使用image，你可以為作業(yè)提供一個(gè)特定的環(huán)境，其中包含所需的軟件、工具和依賴項(xiàng)。讓我們來詳細(xì)了解image的用法和功能。
image存在的地方：

1. 注冊(cè)runner時(shí)指定
2. gitlab-ci.yaml中全局指定
3. gitlab-ci.yaml中job指定

如果全局指定了images則所有作業(yè)使用此image創(chuàng)建容器并在其中運(yùn)行。
全局未指定image，再次查看job中是否有指定，如果有此job按照指定鏡像創(chuàng)建容器并運(yùn)行，沒有則使用注冊(cè)runner時(shí)指定的默認(rèn)鏡像。

#image: maven:3.6.3-jdk-8

before_script:
  - ls
  
  
build:
  image: maven:3.6.3-jdk-8
  stage: build
  tags:
    - newdocker
  script:
    - ls
    - sleep 2
    - echo "mvn clean "
    - sleep 10

deploy:
  stage: deploy
  tags:
    - newdocker
  script:
    - echo "deploy"

services

services關(guān)鍵字用于指定在CI/CD作業(yè)中需要運(yùn)行的附加服務(wù)。通過使用services，你可以在作業(yè)執(zhí)行期間啟動(dòng)和訪問其他容器化的服務(wù)，以滿足作業(yè)的需求。
服務(wù)映像可以運(yùn)行任何應(yīng)用程序，但是最常見的用例是運(yùn)行數(shù)據(jù)庫容器，例如mysql 。與每次安裝項(xiàng)目時(shí)都安裝mysql相比，使用現(xiàn)有映像并將其作為附加容器運(yùn)行更容易，更快捷。

services:
  - name: mysql:latest
    alias: mysql-1

environment

environment關(guān)鍵字用于定義CI/CD作業(yè)的環(huán)境變量。環(huán)境變量是在作業(yè)執(zhí)行期間可用的鍵值對(duì)，用于配置作業(yè)的行為和訪問外部資源。

deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment: # 定義環(huán)境變量
    name: production
    url: https://prod.example.com

常用預(yù)定義環(huán)境變量：文章來源地址http://www.zghlxwxcb.cn/news/detail-820197.html

CI_COMMIT_REF_NAME：作業(yè)所在的分支或標(biāo)簽的名稱。
CI_COMMIT_REF_SLUG：作業(yè)所在的分支或標(biāo)簽的名稱，經(jīng)過URL編碼。
CI_COMMIT_SHA：作業(yè)所在的提交的SHA值。
CI_COMMIT_SHORT_SHA：作業(yè)所在的提交的短SHA值（前7個(gè)字符）。
CI_COMMIT_MESSAGE：作業(yè)所在的提交的提交消息。
CI_COMMIT_TITLE：作業(yè)所在的提交的提交標(biāo)題（第一行）。
CI_COMMIT_DESCRIPTION：作業(yè)所在的提交的提交描述（除了第一行之外的部分）。
CI_JOB_ID：作業(yè)的唯一標(biāo)識(shí)符。
CI_JOB_NAME：作業(yè)的名稱。
CI_PIPELINE_ID：作業(yè)所在的流水線的唯一標(biāo)識(shí)符。
CI_PROJECT_ID：作業(yè)所在的項(xiàng)目的唯一標(biāo)識(shí)符。
CI_PROJECT_NAME：作業(yè)所在的項(xiàng)目的名稱。
CI_PROJECT_PATH：作業(yè)所在的項(xiàng)目的完整路徑。
CI_PROJECT_DIR：作業(yè)所在的項(xiàng)目的根目錄路徑。
CI_RUNNER_ID：GitLab Runner的唯一標(biāo)識(shí)符。
CI_RUNNER_DESCRIPTION：GitLab Runner的描述。
CI_REGISTRY：Docker注冊(cè)表的URL。
CI_REGISTRY_IMAGE：Docker鏡像的名稱（不包含標(biāo)簽）。
CI_REGISTRY_USER：Docker注冊(cè)表的用戶名。
CI_REGISTRY_PASSWORD：Docker注冊(cè)表的密碼。

到了這里，關(guān)于21.云原生之GitLab pipline語法（CI基礎(chǔ)）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！