needs/include/extends/trigger
needs 並行階段
可無序執行作業，無需按照階段順序運行某些作業，可以讓多個階段同時運行。
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:設置爲指向因only/except規則而未實例化的作業，或者不存在，則創建管道時會出現YAML錯誤。
暫時限制了作業在needs:可能需要的最大作業數分配,ci_dag_limit_needs功能標誌已啓用（默認）分配10個，如果功能被禁用爲50。
Feature::disable(:ci_dag_limit_needs) # 50
Feature::enable(:ci_dag_limit_needs) #10
製品下載
在使用needs，可通過artifacts: true或artifacts: false來控制工件下載。 默認不指定爲true。
module-a-test:
stage: test
script:
- echo "hello3a"
- sleep 10
needs:
- job: "module-a-build"
artifacts: true
相同項目中的管道製品下載,通過將project關鍵字設置爲當前項目的名稱，並指定引用，可以使用needs從當前項目的不同管道中下載工件。在下面的示例中，build_job將使用other-refref下載最新成功的build-1作業的工件：
build_job:
stage: build
script:
- ls -lhR
needs:
- project: group/same-project-name
job: build-1
ref: other-ref
artifacts: true
不支持從parallel:運行的作業中下載工件。
include
https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates
可以允許引入外部YAML文件，文件具有擴展名.yml或.yaml 。使用合併功能可以自定義和覆蓋包含本地定義的CI / CD配置。相同的job會合並，參數值以源文件爲準。
local
引入同一存儲庫中的文件，使用相對於根目錄的完整路徑進行引用，與配置文件在同一分支上使用。
ci/localci.yml: 定義一個作業用於發佈。
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
包含來自另一個項目的文件
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進行引用. 遠程文件必須可以通過簡單的GET請求公開訪問，因爲不支持遠程URL中的身份驗證架構。
include:
- remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
extends
繼承模板作業
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
這將運行名爲useTemplate的作業，該作業運行echo Hello! 如.template作業中所定義，並使用本地作業中所定義的alpine Docker映像.
trigger 管道觸發
當GitLab從trigger定義創建的作業啓動時，將創建一個下游管道。允許創建多項目管道和子管道。將trigger與when:manual一起使用會導致錯誤。
多項目管道： 跨多個項目設置流水線，以便一個項目中的管道可以觸發另一個項目中的管道。[微服務架構]
父子管道: 在同一項目中管道可以觸發一組同時運行的子管道,子管道仍然按照階段順序執行其每個作業，但是可以自由地繼續執行各個階段，而不必等待父管道中無關的作業完成。
多項目管道
當前面階段運行完成後，觸發demo/demo-java-service項目master流水線。創建上游管道的用戶需要具有對下游項目的訪問權限。如果發現下游項目用戶沒有訪問權限以在其中創建管道，則staging作業將被標記爲*失敗*。
staging:
variables:
ENVIRONMENT: staging
stage: deploy
trigger:
project: demo/demo-java-service
branch: master
strategy: depend
project關鍵字，用於指定下游項目的完整路徑。該branch關鍵字指定由指定的項目分支的名稱。使用variables關鍵字將變量傳遞到下游管道。 全局變量也會傳遞給下游項目。上游管道優先於下游管道。如果在上游和下游項目中定義了兩個具有相同名稱的變量，則在上游項目中定義的變量將優先。默認情況下，一旦創建下游管道，trigger作業就會以success狀態完成。strategy: depend將自身狀態從觸發的管道合併到源作業。
在下游項目中查看管道信息
在此示例中，一旦創建了下游管道，該staging將被標記爲成功。
父子管道
創建子管道ci/child01.yml
stages:
- build
child-a-build:
stage: build
script:
- echo "hello3a"
- sleep 10
在父管道觸發子管道
staging2:
variables:
ENVIRONMENT: staging
stage: deploy
trigger:
include: ci/child01.yml
strategy: depend
一起學習呀：
