系统运维
.gitlab-ci.yml
.gitlab-ci.yml?用来配置?CI?用你的项目中做哪些操作，这个文件位于仓库的根目录。
当有新内容?push?到仓库，或者有代码合并后，?GitLab?会查找是否有?.gitlab-ci.yml?文件，如果文件存在，?Runners?将会根据该文件的内容开始?build?本次?commit?。
.gitlab-ci.yml?使用?YAML?语法， 你需要格外注意缩进格式，要用空格来缩进，不能用?tabs?来缩进。
Stages
Stages?表示构建阶段，说白了就是上面提到的流程。默认有3个?stages?：?build?,?test?,?deploy?。我们可以在一次?Pipeline?中定义多个?Stages?，这些?Stages?会有以下特点：
所有?Stages?会按照顺序运行，即当一个?Stage?完成后，下一个?Stage?才会开始
只有当所有?Stages?完成后，该构建任务 (Pipeline) 才会成功
如果任何一个?Stage?失败，那么后面的?Stages?不会执行，该构建任务 (Pipeline) 失败
Jobs
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/
跳过job
如果你的?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中添加）
docker Executor
所有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。
更多关于云服务器，域名注册，虚拟主机的问题，请访问西部数码官网：www.west.cn
