温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

.gitlab-ci.yml语法

发布时间:2020-07-13 17:33:00 来源:网络 阅读:880 作者:hellojinni 栏目:系统运维

.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 会有以下特点:

  1. 所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始

  2. 只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功

  3. 如果任何一个 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,回滚的时候点击即可直接跳转到指定位置。

.gitlab-ci.yml语法

手动执行部署

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。




向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI