從7.12版本開始,GitLab CI使用YAML文件(.gitlab-ci.yml)來管理項目配置。該文件存放於項目倉庫的根目錄,它定義該項目如何構建。html
stages
用來定義能夠被job調用的stages。stages的規範容許有靈活的多級pipelines。stages中元素的順序決定了對應job的執行順序:nginx
variables
用來定義變量,全局變量做用於全部job,也能夠在指定的job中定義變量(優先級高於全局變量)
若是在job中想禁用全局定義的變量,可經過variables: {}
定義一個空的哈希值。git
variables | 變量值 |
---|---|
CI_JOB_NAME | 對應的job_name |
GIT_STRATEGY | 指定git獲取代碼的方式(clone,fetch,none) |
jobs
用來定義了一組做業,其中必須包含script
語句。正則表達式
test
)job中指定的stage必須是stages中存在的元素redis
指定該job所容許運行的Runner,必須在註冊Runner時設置Runner的tagcentos
用於指定該job容許執行失敗,則若是執行失敗也不會影響下一個stage的執行。ruby
script
是job中必須指定的語句,指定Runner所要執行的命令服務器
指定script執行前/後所執行的命令,也可定義在全局模式,則在全部job中的script執行前/後都會執行。curl
用於指定job執行成功後,將會被髮送到Gitlab中的文件,且默認狀況下job之間會根據stage的優先級自動下載以前全部stage中的artifacts。ide
artifacts.paths
:必選artifacts.name
:指定artifact的名稱,同時Gitlab上下載的文件名即爲artifact_name.zipartifacts.when
:指定artifact上傳到Gitlab的條件(on_success[默認],on_failure,always)artifacts.expire_in
:指定artifact的過時時間(默認爲30天),使用keep
可永久保存
dependencies
用於在不一樣的job之間指定在不一樣的job之間傳遞artifacts,dependencies: []
可禁止該job下載artifacts
only
和except
是兩個參數用分支策略來限制jobs構建
only
和except
可同時使用。若是在一個job配置中同時存在,則同時有效;only
和except
可使用正則表達式;only
和except
容許使用特殊的關鍵字:branches
,tags
和triggers
;
environment
用於定義job部署到指定的運行環境中。
若是想臨時disable某個job,沒必要註釋整個job定義的行,只需在job name前加一個
.
便可
.compile_centos: stage: build_centos tags: - centos script: - echo "##### build library"
錨點可用於在文件中複製或繼承配置,通常與Hidden keys(jobs)提供的job模版搭配使用。
.job_template: &job_definition #job中定義一個anchor:job_definition image: ruby:2.1 services: - postgres - redis test1: <<: *job_definition #合併anchor:job_definition中的模版內容 script: - test1 project test2: <<: *job_definition script: - test2 project
最終實現的效果以下:
.job_template: image: ruby:2.1 services: - postgres - redis test1: image: ruby:2.1 services: - postgres - redis script: - test1 project test2: image: ruby:2.1 services: - postgres - redis script: - test2 project
若是你的commit信息中包含
[ci skip]
或者[skip ci]
,不論大小寫,那麼這個commit將會建立可是jobs也會跳過。
如下示例爲編譯nginx的上傳模塊nginx-upload並測試驗證上傳功能,驗證成功後將自動將編譯好的文件打包經過curl上傳到指定的文件服務器。其中只有在非master的branches中提交代碼纔會執行build和test的stage,只有在打tag後纔會執行deploy,且須要手動在gitlab上執行。
variables: DIR: nginx TOPNODE: package .function: &function | function build() { echo "execute function:build" chmod +x auto/configure sh build.sh } function changelog() { echo "execute function:changelog" git log --graph -n 3 --name-status --pretty="%h -[%cd] - <%an> %s" > CHANGELOG } function test() { echo "execute function:test" sudo \cp modules/nginx-upload-module-master/nginx.conf /etc/nginx/nginx.conf sudo sed -i '/error_log/,/working_directory/d' /etc/nginx/nginx.conf if [ -f /run/nginx.pid ];then sudo nginx -s reload;else sudo nginx;fi sudo rm -rf /tmp/{0,1,2,3,4,5,6,7,8,9} && sudo mkdir /tmp/{0,1,2,3,4,5,6,7,8,9} && sudo chown -R nginx. /tmp/{0,1,2,3,4,5,6,7,8,9} sudo echo nginx_upload > test && curl -F "filename=@test" http://localhost/upload sudo find /tmp/{0,1,2,3,4,5,6,7,8,9} -type f -exec grep nginx_upload {} \; } function artifacts() { echo "execute function:artifacts" URL="https://xxx.com/upload?dir=${DIR}/${VERSION}&override=1&topNode=${TOPNODE}" echo "push the artifacts:nginx_${VERSION}.tar.gz to $URL" tar zcf /tmp/nginx_${VERSION}.tar.gz --exclude=".git*" --exclude=build . curl -F "filename=@/tmp/${DIR}_${VERSION}.tar.gz" "$URL" echo "push the CHANGELOG to $URL" curl -F "filename=@CHANGELOG" "$URL" } function deploy() { echo "execute function:deploy" } function clean() { echo "execute function:clean" if [ -f /run/nginx.pid ];then sudo kill `cat /run/nginx.pid`;fi sudo rm -rf /tmp/{0,1,2,3,4,5,6,7,8,9} /tmp/nginx_${version}.tar.gz } #########only the section above need to be modify ################# before_script: - VERSION=`head -n1 version` - *function stages: - build - test - deploy build: stage: build only: - branches except: - master script: - build - changelog test: stage: test variables: GIT_STRATEGY: none only: - branches except: - master script: - test - artifacts - clean .job_template: &deploy_template stage: deploy variables: GIT_STRATEGY: none only: - tags script: - deploy - delete when: manual staging: <<: *deploy_template environment: name: staging production: <<: *deploy_template environment: name: production