网站开发工资高吗,人才网网站开发手册,建设网站费用如何做账,申请网站就是做网站吗工作原理
1、将代码托管在git 2、在项目根目录创建ci文件.gitlan-ci.yml 在文件中指定构建#xff0c;测试和部署脚本 3、gitlab将检测到他并使用名为git Runner的工具运行脚本 4、脚本被分组为作业#xff0c;他们共同组成了一个管道gitlab-ci的脚本执行#xff0c;需要自…
工作原理
1、将代码托管在git 2、在项目根目录创建ci文件.gitlan-ci.yml 在文件中指定构建测试和部署脚本 3、gitlab将检测到他并使用名为git Runner的工具运行脚本 4、脚本被分组为作业他们共同组成了一个管道gitlab-ci的脚本执行需要自定义按照对应的gitlab-runner来执行代码push之后 webhook检测到代码变化就会触发gitlan-ci分配到各个Runner来运行相应的脚本script
gitlab Runner
类型 shared 共享类型运行整个平台项目的作业gitlab group 项目组类型运行特定group下的所有项目的作业group sprcific 项目类型运行指定的项目作业project
状态 locked 锁定状态无法运行项目作业 paused 暂停状态暂时不会接收新的作业
流水线语法
job作业
在每个项目中使用名为.gitlab-ci.yml的YML文件配置Gitlab CL/CD管道在文件中可以定义一个或多个作业job每个作业必须具有唯一名称不能使用关键字每个作业是独立运行的作业定义了在约束条件下进行相关操作每个作业至少要包含一个script.
例 job1 script: execute-script-for-job1 job2: script: execute-script-for-job2
这里定义了两个作业每个作业运行不同命令命令可以是shell或脚本
script
(运行shell或者脚本
列
job1: script: - uname -a - bundle exec rspec
注意有时script命令需要用单引号或双引号引起来例如包含冒号命令:需要加引号以便被包裹的YAML解析器知道来解释整个事情作为一个字符串而不是一个“键值”对,使用特殊字符是消息:,{,},[,],,,*,#,?,|,-,,,,!,%,,
before_script
用于定义一个命令在该命令在每个作业之前运行。必须是一个数组。知道的scripy与脚本中知道的任何脚本串联在一起并在单个shell中一起执行 before_script失败导致整个作业失败其他作业将不再执行。作业失败不会影响after_script
after_script
用于定义将每个作业包括失败的作业之后运行的命令 这必须是一个数组 指定的脚本在新的shell中执行与任何before_script或script脚本分开 before_script或script执行失败不影响after_script执行
stages
用于定义作业可以使用的阶段并且是全局定义 同一阶段的作业并行运行不同阶段按顺序执行
stages: - build - test - codescan - deploy
.pre.post
.pre始终是整个管道的第一运行阶段.post始终是整个管道的最后一个运行阶段。用户定义的阶段都在两者之间运行。.pre和.post的顺序无法更改。如果管道仅包含.pre或.post阶段的作业则不会创建管道
codescan: stage: .pre tags: - build only: - master script: - echo codescan
stage
按job定义的并且依赖与全局定义的stages。它允许将作业分为不同的阶段并且统一stage作业可以并行执行
varibales
定义变量pipeline变量、job变量。job变量优先级最大
tags
指定runner 用于从允许该项目的所有Runner列表中选择指定的Runner,在Runner注册期间你可以指定Runner的标签
windows job: stage: - build tags: - windows script: - echo Hello,%$USERNAME%: osx job: stage: - build tags: - osx script: - echo Hello, $USER:
allow_failure允许失败
allpw_failure允许作业失败默认值为false启用后如果作业失败改作业将在用户界面显示橙色警告但是管道的逻辑流程将任务作业成功/通过并且不会被阻塞。假设所有其他作业均成功则改作业的阶段及其管道将显示相同的橙色警告。但是管理的提交将被标记为通过而不会发出警告。
windows job: stage: - build tags: - windows script: - echo Hello,%$USERNAME%: allow_failure: true
when(控制作业允许)
on_success 前面阶段中的所有作业都成功时才执行作业默认值 on_failure 当前面阶段出现失败时执行 always 总是执行作业 manual 手动执行作业 delayed 延迟执行作业
retry(重试)
配置在失败的情况下重试作业的次数 当作也失败并配置了retry将再次处理该作业直到达到retry关键字指定的次数 如果当retry设置为2斌却作业在第二次允许成功第一次重试则不会再次重试retry值必须是一个正整数等于或大于0小于或等于2最多两次重试总共允许三次
retry-重试-精确匹配错误
默认情况下在失败情况下重试作业max最大重试次数 when重试失败的错误类型
always 在发生任何故障时重试默认. unknown_failure 当失败原因未知时。 script_failure 脚本失败时重试。 api_failure API失败重试。 stuck_or_timeout_failure 作业卡住或超时时。 runner_system_failure 运行系统发生故障。 missing_dependency_failure: 如果依赖丢失。 runner_unsupported Runner不受支持。 stale_schedule 无法执行延迟的作业。 job_execution_timeout 脚本超出了为作业设置的最大执行时间。 archived_failure 作业已存档且无法运行。 unmet_prerequisites 作业未能完成先决条件任务。 scheduler_failure 调度程序未能将作业分配给运行scheduler_failure。 data_integrity_failure 检测到结构完整性问题。
例
unittest: stage: test tags: - build only: - master script: - ech run test retry: max: 2 when: - script_failure
timeout-超时
作业级别的超时可以超过项目级别超时但不能超过Runner特定的超时 build: script: build.sh timeout: 3hours 30minutes test: script: rspec timeout: 3h 30m
timeout-超时-runner超时
如果小于项目定义超时时间将具有优先权此功能可用于通过设置大超时例如一个星期来防止Shared Runner被项目占用。未配置时 Runner将不会覆盖项目超时
示列1运行程序超时大于项目超时 runner超时设置为24小时项目的CI/CD超时设置为2小时。 该工作将在2小时后超时
示例2未配置运行程序超时 runner不设置超时时间项目的CI/CD超时设置为2小时 该工作将在2小时后超时
示例3运行程序超时小于项目超时 runner超时设置为30分钟项目的CI/CD超时设置为2小时 工作在30分钟后超时
parallel-并行作业
配置要并行运行的作业实例数此值必须大于或等于2并且小于或等于50 这将创建n个并行运行的同一作业实例、他们从job_name 1/n到job_name n/n依次命名
onlyecxept限制分支标签
only和ecxept用分支策略来限制jobs构建 only定义那些分支和标签的git项目将会被job执行 ecxept定义那些分支和标签的git项目将不会被job执行
job: #use regexp only: - /^issue-.*$/ #use specli keyword ecxept: - branches
rules-构建规则
rules允许按顺序苹果单个规则直到匹配并为作业动态提供属性 rules不能与only/except组合使用 可用规则 if 如果条件匹配 changes 指定文件发生变化 exists 指定文件存在
列rules-if-条件匹配
如果DOMAIN的值匹配则需要手动运行 不匹配on_success 条件判断从上到下匹配即停止 多条件匹配可以使用||
variables: DOMAIN: example.com codescan: stage: codescan tags: - build script: - echo codescan - sellp 5; #parallel:5 rules: - if:$DOMAIN example.com when: manual when: on_success
rules-changes-文件变化
接受文件路径数组 如果提交jenkinsfile文件发送的变化则为true
codescan: stage: codescan tags: - build script: - echo codescan - sleep 5; #parallel5 rules: - changes: - jenkinsfile when: manual - if:$DOMAIN example.com when: on_success - when: on_success
rules-allow_failure-允许失败
使用rules-allow_failure: true rules:在不停止管道本身的情况虚啊允许作业失败或手动作业等待操作
job: script echo Hello,Rules rules: - if:$CI_meRGE_REQUEST_TARGET_BRABCH_NAME master when: manual allow_failure
workflow-rules-管道创建
定价workflow关键字适用于整个管道并将确定是否创建管道 when可以三个字为always或never如果未提供则默认值未always
variables: DOMAIN: example.com workflow: rules: - if: $DOMAIN example.com - when: always
cache-缓存
存储编译项目所需运行时的依赖项指定项目工作空间钟需要在job之间缓存吃的文件目录 全局cache定义在job之外针对所有job生效。job钟cache优先于全局
cache:paths
在job build中定义缓存将会缓存target目录下的所有jar文件 挡在全局定义了cachepaths会被job覆盖一下实例将缓存target
build: script: test cache: paths: - target/*.jar
cache: paths: - my/files build: script: echo Hello cache: key: build paths: - target/
由于缓存是在job之间共享的如果不同的job使用不同的路径就出现了缓存覆盖的问题 如何让不同的job缓存不同的cache呢 设置不同的cachekey
cachekey-缓存标记
为缓存做个标记可以配置job、分支为key来实现分支、作业特定的缓存 为不同job定义了不同的cachekey时会为每个job分配一个独立的cache cachekey变量可以使用任何预定义变量默认default 从gitlab9.0开始 默认情况下所有内容都在管道和作业之间共享
按分支设置缓存
cache: key: ${CI_COMMIT_REF_SLUG}
cache:keyfiles-文件变化自动创建缓存 files: 文件发送变化自动重新生成缓存files最多指定两个文件提交的时候检查指定的文件 根据指定的文件生成密钥计算sha校验和如果文件未改变值为default
cache: key: files: - Gemfile.lock - package.json paths: - endor/ruby - node_modules
cache:keyprefix-组合生成sha校验和
prefix: 允许给定prefix的值与指定文件生成的密钥组合 在这里定义了全局的cache如果文件发送变化则值未repec-xxx11122211如未发生变化未rspec-default
cache: key: files: - Gemfile.lock prefix: $(CI_JOB_NAME) path: - vendor/ruby rspec: script: - bundle exec rspec
cache:policy-缓存策略
默认在执行开始下载文件并在结束时重新上传文件 policypull跳过下载步骤policypush跳过上传步骤
artifacts-制品 用于指定在作业成功或者失败是应附加到作业的文件或目录的列表作业完成后工件将被发送到gitlab并可在gitlab ui中下载
artifacts: paths: - target/
例
default-job: script: - mvn test -U except: - tags release-job: script: - mvn package -U artifacts: path: - target/*.war oniy: - tags
artifacts:expose_as-MR展示制品
关键字expose_as可用于在合并请求UI中公开作业工件 每个合并请求最多可以公开10个作业工件
列
test: script: - echo 1 aritifacts: expose_as:artifact 1 patchs: - path/to/file.txt
artifacts:name-制品名称
通过name指令定义所创建的弓箭存档的名称可以为每个档案使用唯一的名称 artifacts:name默认名称是artifacts下载artifacts改为artifacts.zip
列
job: artifacts: name: $CI_JOB_NAME patchs: - binaries/ job: artifacts: name: $CI_COMMIT_REF_NAME paths: - binaries/
artifacts:when-制品创建条件
用于在作业失败时或成功上传工件 on_success仅在作业成功时上载工件 默认值 on_failure仅在作业失败时上传工件 always 上传工件无论作业状态如何
例
job1: artifacts: when: on_failure job2: artifacts: when: on_success job3: artifacts: when: always
artifacts:expire_in-制品保留时间
制品的有效期从上传和存储到gitlab的时间算起如果未定义过期时间则默认为30天 expire_in的值以秒为单位的警告时间除非提供了单位
例
job: artifacts: expire_in: 1 week
artifacts:reports:junit-单元测试报告
收集junit单元测试报告收藏JUnit报告将作为工作上传到gitlab并将自动显示在合并请求中
列
build: stage: build tags: - build only: - master script: - mvn test - mvn cobertura:cobertura - ls target artifacts: name: $CI_JOB_NAME-$CI_COMMIT_REF_NAME when: on_success expose_api: artifact 1 paths: - target/*,jar reports junit: target/surefire-reports/TEST-*.xml
dependencies-获取制品
定义要获取工件的作业列表只能从当前阶段之前执行的阶段定义作业定义一个空数组将跳过下载该作业的任何工件将不会考虑先前作业的状态因此如果它失败或是未运行的手动作业则不会发生错误。如果设置未依赖项的工作工件已过期或删除那么依赖项作业将失败。 列
unittest: dependencies: - build
needs-阶段并行
可无序执行作业无需按阶段顺序运行某些作业可以让多个阶段同时运行。 如果needs设置为指向因only/except规则而未实例化的作业或者不存在则创建管道时会出现YML错误
列
module-a-test: stage: test script: - echo Hello - sleep 10 needs: - job: module-a-build
needs-制品下载
在使用needs可通过artifacts: true或artifacts: false来控制工件下载默认不知道为true 列
module-a-test: stage: test script: - echo Hello - sleep 10 needs: - job: module-a-build artifacts: true
include:local-引入本地配置
可以允许引入外部YAML文件文件具有扩展名.yml或yaml 使用合并功能可以自定义和覆盖包含本地定义的CI/CD配置 引入同一存储库中得文件使用相对于根目录得完整路径进行引用与配置文件在同一分支上使用 列
ci/localci.yml
stages: - deploy deployjob: stage: deploy script: - echo deploy
include: local: ci/localci.yml
include:file-引入其他项目配置
引入另外项目master分支的.gitlab-ci.yml配置
include: - project: 项目名称 ref: master file: .gitlab-ci.yml
include-template-引入官方配置
https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates
include: - template: AUTO-DevOps.gitlab-ci.yml
include:remote-引入远程配置
用于通过HTTP/HTTPS包含来自其他位置的文件并使用完整URL进行引用远程文件必须可以通过简单的GET请求公开访问因为不支持远程URL中的身份验证
include: - remote: https://gitlab.com/awesome-project/raw/master/.gitlan-ci-template.yml
extends-继承作业配置 .tests: script: mvn test stage: test only: refs: - tags testjob: extends: .tests script: mvn clent test only: cariables: - $RSPEC testjob: stage: test script: mvn clent test only: variables: - $RSPEC refs: - tags
extendsinclude
这将运行名为useTenplate的作业该作业运行echo Hello 如.template作业中所定义并使用本地作业中所定义的apline Docker映射 aa.yml
.template: script: - echo Hello
include: aa.yml
useTemplate: image: alpine extends: .template
trigger管道触发
当gitlab从trigger定义创建的作业启动时将创建一个下游管道允许创建多项目管道和子项目管道将trigger于whenmonual一起使用会导致报错 多项目管道跨多个项目设置流水线以便一个项目中的管道可以触发另一个项目中的管道 父子管道在同一项目管道可以触发一组同时运行的子管道子管道仍然按照阶段顺序执行其每个作业但是可以自由地继续执行各个阶段而不必等待父管道中无关的作业完成
image
默认在注册runner的时候需要填写一个基础的镜像请记住一点只要使用执行器为docker类型的runner所以的操作运行都会在容器中运行如果全局指定了images则所以作业使用此image创建容器并在其中运行全局未指定image再次查看job中是否有指定如果有此job按照指定镜像创建容器并运行没有则使用注册runner时指定的默认镜像
build: image: 镜像名称:标签 stage: build tags: - aws - docker script: - ls - sleep 2 - mvn clen package - sleep 10 depal: stage: deplay tags: - aws script: - echo deplay
services
工作期间运行的另一个docker镜像并link到image关键字定义的docker镜像。这样就可以在构建期间访问服务映像 服务映像可以运行任何程序但是最常见的用例是运行数据库容器例如mysql与每次按照项目时都安装mysql相比 使用现有的映像并将其作为附加容器运行更容易更快捷
services: - name: mysql:latest alias: mysql-1 #别名
environment
工作期间运行的另一个docker映像并link到image关键字定义的docker映像这样在构建期间访问服务映像
deolay to production: stage: deplay script: git push production HEAD:master environment: name: production #部署环境名称 url: http://prod.example.com #部署环境地址
inherit
使用或禁用全局定义的环境变量variables或默认值default 使用true、false觉得是否使用默认为true
inherit: default: false variables: false
继承其中的一部分变量或默认值使用list
inherit: default: - parameter1 - parameter1 variables: false - VARIABLE1 - VARIABLE2
创建CI模板库
1.创建一个git仓库用于存放模版 2.创建一个template目录存放所有pipeline的模版 3.创建一个jobs目录存放job模版 这样我们可以将一些mavenant,gradle,npm工具通过一个job模版和不同的构建命令实现templates的好处时我们在其中定义了模版流水线这些流水线可以直接让项目使用当遇到个性化项目的时候就可以在当前姓名创建.gitlab-ci.yml文件来引用模版文件再进一步实现个性化需要
工具链集成
后端项目Maven集成
环境基础配置 首先在jobs目录创建一个build.yml然后在里面编写build作业模版
.build: stages: build tags: - build script: - $BUILD_SHELL - ls
然后在template目录中创建maven流水线模版。templates/java-pipeline.yml
include: - project: demo/demo-gitlabci-service ref: master file: jobs/build.yml variables: BUILD_SHELL: mvn clean package -DskipTests #构建命令 TEST_SHELL: mvn test #测试命令 CACHE_DIR: target/ #构建缓存 cache: paths: - ${CACHE_DIR} stages: - build
build: stage: build extends: .build
工具链集成-代码质量管理平台集成
SonarQube自动扫描 安装sonarscanner
https://docs.sonarqube.org/latest/setup/get-started-2-minutes/
