.gitlab-ci.yml 用来配置 CI 用你的项目中做哪些操作,这个文件位于仓库的根目录。
当有新内容 push 到仓库,或者有代码合并后, GitLab 会查找是否有 .gitlab-ci.yml 文件,如果文件存在, Runners 将会根据该文件的内容开始 build 本次 commit 。
.gitlab-ci.yml 使用 YAML 语法, 你需要格外注意缩进格式,要用空格来缩进,不能用 tabs 来缩进。
Stages 表示构建阶段,说白了就是上面提到的流程。默认有3个 stages : build , test , deploy 。我们可以在一次 Pipeline 中定义多个 Stages ,这些 Stages 会有以下特点:
所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始
只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功
如果任何一个 Stage 失败,那么后面的 Stages 不会执行,该构建任务 (Pipeline) 失败
Jobs 表示构建工作,表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs ,这些 Jobs 会有以下特点:
1、相同 Stage 中的 Jobs 会并行执行
2、相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功
3、如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败
任务中必须得有 script 部分。
# 定义 stages(阶段)。任务将按此顺序执行。
stages:
- build
- test
- deploy
# 定义 job(任务)
job1:
stage: test
tags:
- XX #只有标签为XX的runner才会执行这个任务
only:
- dev #只有dev分支提交代码才会执行这个任务。也可以是分支名称或触发器名称
- /^future-.*$/ #正则表达式,只有future-开头的分支才会执行
script:
- echo "I am job1"
- echo "I am in test stage"
# 定义 job
job2:
stage: test #如果此处没有定义stage,其默认也是test
only:
- master #只有master分支提交代码才会执行这个任务
script:
- echo "I am job2"
- echo "I am in test stage"
allow_failure: true #允许失败,即不影响下步构建
# 定义 job
job3:
stage: build
except:
- dev #除了dev分支,其它分支提交代码都会执行这个任务
script:
- echo "I am job3"
- echo "I am in build stage"
# 定义 job
.job4: #对于临时不想执行的job,可以选择在前面加个".",这样就会跳过此步任务,否则你除了要注释掉这个job4外,还需要注释上面为deploy的stage
stage: deploy
script:
- echo "I am job4"
# 模板,相当于公用函数,有重复任务时很有用
.job_template: &job_definition # 创建一个锚,'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
#下面几个都相当于全局变量,都可以添加到具体job中,这时会被子job的覆盖
before_script:
- echo "每个job之前都会执行"
- export MVN_HOME
- export JAVA_HOME
- java -version
- sh /home/gitlab-runner/kill.sh
after_script:
- echo "每个job之后都会执行"
variables: #变量
DATABASE_URL: "postgres://postgres@postgres/my_database" #在job中可以用${DATABASE_URL}来使用这个变量。常用的预定义变量有CI_COMMIT_REF_NAME(项目所在的分支或标签名称),CI_JOB_NAME(任务名称), CI_JOB_STAGE(任务阶段)
GIT_STRATEGY: "none" #GIT策略,定义拉取代码的方式,有3种:clone/fetch/none,默认为clone,速度最慢,每步job都会重新clone一次代码。我们一般将它设置为none,在具体任务里设置为fetch就可以满足需求,毕竟不是每步都需要新代码,那也不符合我们测试的流程
cache: #缓存
#因为缓存为不同管道和任务间共享,可能会覆盖,所以有时需要设置key
key: ${CI_COMMIT_REF_NAME} # 启用每分支缓存。
#key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME" # 启用每个任务和每个分支缓存。需要注意的是,如果是在windows中运行这个脚本,需要把$换成%
untracked: true #缓存所有Git未跟踪的文件
paths: #以下2个文件夹会被缓存起来,下次构建会解压出来
- node_modules/
- dist/
如果你的 commit 信息包涵 [ci skip] 或者 [skip ci] ,不论大小写,这个 commit 将会被创建,但是 job 会被跳过
版本回滚
stages:
- build
- deploy
build_job:
stage: build
tags:
- test1
script:
- echo "this is a test !"
dev_job:
stage: deploy
tags:
- test1
environment:
name: v2
url: http://www.test.com
script:
- echo "this is a deploy !"
environment: 是配置在deploy这个stage里面的,用于后面Environments可以做版本回滚。
红色部分是URL,回滚的时候点击即可直接跳转到指定位置。
stages:
- build
- deploy
build_job:
stage: build
tags:
- test1
script:
- echo "this is a test !"
dev_job:
stage: deploy
tags:
- test1
environment:
name: v2
url: www.baidu.com
script:
- echo "this is a deploy !"
when: always #不管前面几步成功与否,永远会执行这一步。它有几个值:on_success (默认值)\on_failure\always\manual(手动执行)
每次提交代码就会自动触发构建并自动发布,production的构建发布需要手动点击按钮,这个是when: manual实现的。
when 用于实现在出现故障或运行失败时运行的作业。
when 可以设置为以下值之一:
on_success - 只有当前一个阶段的所有工作成功时才执行工作。这是默认值。
on_failure - 仅当前一个阶段的至少一个作业发生故障时才执行作业。
always - 无论前一阶段的工作状况如何,继续执行工作。
manual - 手动执行作业(在GitLab 8.10中添加)
所有jobs的执行环境为指定的docker image所生成的container,每个job都会生成一个container并且在job结束后立即销毁。
Pull policies
当你使用docker 或 docker+machine executors时,你可以通过设置pull_policy来决定Runner如何pull docker image。pull_policy有三种值:
always —— Runner始终从远程pull docker image。
if-not-present —— Runner会首先检查本地是否有该image,如果有则用本地的,如果没有则从远程拉取。
never —— Runner始终使用本地的image。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。