.gitlab-ci.yml语法
发布时间：2024-05-01 点击：73
系统运维
.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_failur
电子商务常识整理
请恢复网站-域名及账户问题
微软“三朵云”在华团聚，能否改变云市场格局？
海外虚拟主机丨2020年建站主机推荐
网站自从换了机房几乎每天都是错误
怎么用xshell连接云服务器
百度云服务器没硬盘吗
如何不备案访问腾讯云服务器系统
.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_failur
电子商务常识整理
请恢复网站-域名及账户问题
微软“三朵云”在华团聚，能否改变云市场格局？
海外虚拟主机丨2020年建站主机推荐
网站自从换了机房几乎每天都是错误
怎么用xshell连接云服务器
百度云服务器没硬盘吗
如何不备案访问腾讯云服务器系统