从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