gitrunner配置_gitlab-ci配置详解（⼀）
近期因为折腾gitlab-ci，专门去翻了很多⽂档，想想貌似⾃⼰挺傻的。按照官⽹教程本来biubiubiu就弄好了，⾮⾃⼰折腾了好⼏天，还没啥积累，真是作。想想唯⼀能积累的就是ci的配置详解了。
该⽂基于最新版GitLab Community Edition 10.1.1和GitLab Runner9.5.1-1
使⽤.l配置你的项⽬
这篇⽂档描述了.l的⽤法，本⽂件是被gitlab runner⽤于管理你的项⽬任务。
如果你想要快速查看Gitlab CI的介绍，请点击这⾥ 快速开始向导
.l
从版本7.12开始,GitLab CI使⽤YAML⽂件(.l)对你的项⽬进⾏配置。该⽂件放置在你项⽬的根⽬录下，并且包涵了你的项⽬如何被编译的描述语句。
YAML⽂件使⽤⼀系列约束叙述定义了“任务”启动时所要做的事情。“任务”被定义为具名的顶级元素，并且⾄少包括⼀条脚本语句：
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
上⾯的例⼦是两个在ci中能起作⽤的最简单的，分离的任务，每⼀个任务执⾏⼀条不同的命令。
当然了，⼀条命令会⽴即在克隆的仓库中执⾏⼀句语句(例如：./configure;make;make install)或者启动⼀个脚本(例如test.sh)
任务会被Runners拿到并在Runner的环境下被执⾏。重要的是，每个任务将会独⽴进⾏，与其他任务分离开来。
YAML语法允许我们使⽤更复杂的任务声明，例如下⾯的例⼦：
# docker镜像
image: ruby:2.1
# 依赖的docker服务
services:
- postgres
# 开始执⾏脚本前所需执⾏脚本
before_script:
- bundle install
# 脚本执⾏完后的钩⼦，执⾏所需脚本
after_script:
- rm secrets
# 该ci pipeline适合的场景
stages:
-
build
- test
- deploy
# 定义的任务1
job1:
# 场景为构建
stage: build
# 所需执⾏的脚本
script:
- execute-script-for-job1
# 在哪个分⽀上可⽤
only:
- master
# 指定哪个ci runner跑该⼯作
tags:
- docker
以下是⼀些不可被⽤于任务名的保留字：关键字
是否必须
描述
image
no
使⽤的docker镜像，
services
no
使⽤的docker服务，
stages
no
定义构建场景
types
no
stages的别名(不赞成使⽤)
before_script
no
定义每个任务的脚本启动前所需执⾏的命令after_script
no
定义每个任务的脚本执⾏结束后所需执⾏的命令
variables
no
定义构建变量
cache
no
定义哪些⽂件需要缓存，让后续执⾏可⽤
image and services
这两个选项允许我们指定任务运⾏时所需的⾃定义的docker镜像和服务，这两个选项的配置在以下⽂档中有涉及
before_script
before_script是⽤于定义⼀些在所有任务执⾏前所需执⾏的命令, 包括部署⼯作(但是是在job环境⼿动恢复之后执⾏)。可以接受⼀个数组或者多⾏字符串。
after_script
在GitLab 8.7引进，需要GitLab Runner v1.2以上的版本
after_script⽤于定义所有job执⾏过后需要执⾏的命令. 可以接受⼀个数组或者多⾏字符串。
注意: before_script和script在⼀个上下⽂中是串⾏执⾏的，after_script是独⽴执⾏的，所以根据执⾏器(在runner注册的时候，可以选择执⾏器，docker,)的不同，⼯作树之外的变化可能不可见，例如，在before_script中执⾏软件的安装。
注意：你可以在任务中定义before_script，after_script，也可以将其定义为顶级元素，定义为顶级元素将为每⼀个任务都执⾏相应阶段的脚本或命令
stages
stages是⽤于定义场景阶段，可以被任务所使⽤⽤于定义所属场景阶段。stages的允许定义多个，灵活的场景阶段的pipline。
stages定义的元素的顺序决定了任务执⾏的顺序:
1.任务指定的stage名相同，该多个任务将并⾏执⾏(但是经过测试，貌似也是按照A-Z的头字母顺序顺序执⾏的。。只是GitLab-UI上看着是并⾏。。。)
2.下⼀个场景阶段的任务将会在前⼀个场景阶段的任务都完成的情况下执⾏
让我们来思考⼀下下⾯的例⼦，下⾯的例⼦定义了3个场景阶段:
stages:
- build
- test
- deploy
1.⾸先, 所有build场景的任务将被并⾏执⾏.
2.如果所有build场景的任务都成功了, test场景的所有任务将会并⾏执⾏.
3.如果所有test场景的任务都成功了, depoly场景的所有任务将会执⾏.
4.如果所有depoly场景的任务都成功了, 提交将会标记为成功.
5.如果其中某⼀步场景某⼀个任务失败了, 那么提交将会被标记为失败，并且之后的场景和任务将不会执⾏.
这⾥也有两种边缘情况值得⼀说：
如果在.l中没有定义stages,build、test、deploy将是任务可设定的场景阶段的默认值.
如果⼀个任务没有指定场景阶段，该任务将会默认为test场景阶段，
types
不赞成使⽤，在未来的发⾏版中将会被移除，请使⽤stages代替
为stages的别名
variables
由GitLab Runner v0.5.0引⼊
GitLab CI允许你为.l增加变量，该变量将会被设置⼊任务环境。这些变量是你存储在git仓库⾥，并且⾮敏感的项⽬配置，例如:
variables:
DATABASE_URL: "postgres://postgres@postgres/my_database"
注意：整数和字符串⼀样，对于设置变量名和变量值来说都是合法的。但浮点数是⾮法的。
这些变量在之后的所有命令和脚本中都能使⽤。并且YAML⽂件定义的变量同样会被设置到所有被⽤户创建的服务容器⾥。重要的是，变量也可以定义在⼀个任务级别中
job1:
variables:
STATIC_PATH: "./"
除了⽤户定义的变量，你的运⾏环境中也有⼀些由Runner射只的变量，其中⼀个例⼦是CI_COMMIT_R
EF_NAME变量，该变量的值表⽰了正在构建的项⽬的分⽀或者标签名。除了⽤户设置的变量之外，gitlab的ui也能设置⼀些“秘密变量”。详细见⽂档【variables】
cache
注意：
git使用详解由gitlab runner v0.7.0引⼊
在GitLab 9.2之前，缓存将会在artifacts被下载之后(artifacts详见配置详解⼆)被重置
在此之后，缓存将会在artifacts被下载之前被重置
cache⽤于指定⼀些需要在任务间进⾏缓存的⽂件和⽬录，你只能使⽤项⽬⼯作空间内的路径来指定缓存。下⾯是⼀个例⼦
stages:
- pre_build
- build
cache:
key: ${CI_BUILD_REF_NAME}
paths:
- node_modules/
pre_build:
stage: pre_build
script:
- npm install
在GitLab9.0以后，我们默认启⽤了pipelines和jobs之间的缓存共享！
如果cache定义在jobs的作⽤域外(就是做为顶级元素)，则这意味着这个设置是全局的，所有任务都会使⽤该定义(使⽤的意思是Checking cache for default，
Successfully extracted cache。从默认缓存存储位置拉取缓存)。
缓存binaries和.config下的所有⽂件(我实验过了，缓存定义在job⾥，1个是没有⽤的，两个job定义了相同的缓存，他们才会从 default cache path ⾥被到)
rspec:
script: test
cache:
paths:
- binaries/
- .config
缓存所有未追踪的⽂件：
rspec:
script: test
cache:
untracked: true
缓存binaries⽂件夹和所有未追踪的⽂件
rspec:
script: test
cache:
untracked: true
paths:
- binaries/
使⽤任务中的缓存重写全局设置，下⾯的rspec任务只会缓存binaries⽂件夹
cache:
paths:
-
my/files
rspec:
script: test
cache:
key: rspec
paths:

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。