美文网首页
Gitlab CI 使用高级技巧

Gitlab CI 使用高级技巧

作者: cain07 | 来源:发表于2020-07-17 16:57 被阅读0次

    在.gitlab-ci.yml中配置你的工作流


    这篇文章描述了.gitlab-ci.yml的用法,.gitlab-ci.yml文件被Gitlab Runner用来管理你的jobs。
    从7.12版本开始,Gitlab CI 用YAML文件(.gitlab-ci.yml)来配置项目。它被放置在你仓库的根目录并且应该包含YAML如何构建你项目的定义。如果你先要Gitlab CI的快速介绍,可以看下我们的快速快开始指导

    注意:如果你有镜像仓库需要Gitlab去拉取,你可能需要开启pipeline triggering,在你的项目中设置Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates.

    Jobs


    YAML文件定义了一些job,这些job限制了他们应该被运行的时间。你可以在文件的顶层中指定无限的job,他们可以随意命名,并且至少包含一个script条目

    job1:
      script: "execute-script-for-job1"
    
    job2:
      script: "execute-script-for-job2"
    
    

    上面的例子是CI/CD配置可以的最简单的配置,有两个分离的job,每一个job执行不同的命令,当然命令可以直接在仓库中执行代码(./configure; make;make install)或者运行脚本(test.sh).
    Job被Runner挑选出来,并且在Runner环境中执行,最重要的是每个Job相对与其他Job是独立运行的。
    每个Job必须包含唯一的名字,但是这里有一些保留的关键字不能被用作Job的名称:

    • image
    • services
    • stages
    • types
    • before_script
    • after_script
    • variables
    • cache

    一个job通过以下一些定义job行为的参数定义而成。

    关键字 是否必须 描述
    script yes 定义Runner执行的shell脚本
    extends no 定义当前job继承配置的入口
    image no 定义脚本镜像,涵盖在Docker镜像使用
    services no 使用docker services,涵盖在使用Docker镜像
    stage no 定义job的stage(默认:test)
    type no stage的别名
    variables no 在job层定义变量
    only no 定义创建job的git refs的列表
    except no 定义不创建job的git refs的列表
    tags no 定义用来选择Runner的tag列表
    allow_failure no 允许job失败,失败的job无助于commit的状态
    when no 定义何时运行job可以是on_success,on_failure,always或者manual
    dependencies no 定义另外的job作为当前job的依赖,这样你就可以在他们之间传递工件
    artifacts no 定义job工件列表
    cache no 定义应该被缓存起来的东西,以便在下次run的时候使用
    before_script no 定义在job之前执行的命令列表
    after_script no 定义在job之后执行的命令列表
    environment no 定义由该job完成发布的环境的名称
    converage no 定义该job代码覆盖率的设置
    retry no 定义在失败的情况下可以自动重试多少次
    parallel no 定义多少job实例可以同时运行

    extends

    在Gitlab11.3中引入

    extends定义继承的job的名称。他是使用YAML anchors的替代方案,它更加灵活,并且可读性更强:

    .tests:
      script: rake test
      stage: test
      only:
        refs:
          - branches
    
    rspec:
      extends: .tests
      script: rake rspec
      only:
        variables:
          - $RSPEC
    
    

    在上面的例子中rspc这个job继承了.tests这个模版job。GitLab将会根据keys执行反向深度合并。Gitlab将会:

    • 递归合并rspec的内容到.tests
    • 不合并键的值

    rspec job的结果如下:

    rspec:
      script: rake rspec
      stage: test
      only:
        refs:
          - branches
        variables:
          - $RSPEC
    
    

    注意:script: rake test已经被script:rake rspec合并了。

    如果你想要包含rake test,看看before_script-and-after_script.
    .tests在这个例子中是一个隐藏的key,但是它也可以继承自正常的job.
    extends支持多层继承,但是不建议超过三层的继承。最多支持的嵌套层级是10层。下面的例子有两个层级的嵌套。

    .tests:
      only:
        - pushes
    
    .rspec:
      extends: .tests
      script: rake rspec
    
    rspec 1:
      variables:
        RSPEC_SUITE: '1'
      extends: .rspec
    
    rspec 2:
      variables:
        RSPEC_SUITE: '2'
      extends: .rspec
    
    spinach:
      extends: .tests
      script: rake spinach
    
    

    跨文件的extend结合include一起使用

    pages

    pages是一个特殊的job,它被用来上传一些服务网站的静态资源到GitLab.它有特殊的语法,必须满足以下两点:

    1. 所有的静态资源必须在public/目录下
    2. artifacts的path地址必须被定义成public/

    下面的例子简单的将所有文件从根目录下移动到public/文件下。使用.public所以cp命令不会无限循环的拷贝public/到它自己目录下

    pages:
      stage: deploy
      script:
        - mkdir .public
        - cp -r * .public
        - mv .public public
      artifacts:
        paths:
          - public
      only:
        - master
    
    

    详情阅读GitLab Pages user documentation.

    image 和 services

    该字段允许指定在job工作时间可用的自定义的Docker镜像和services列表。此功能的介绍在单独的文章中介绍。

    before_script 和 after_script

    注意:在GitLab8.7中引入,并且需要Runner V1.2

    before_script被用来定义一些需要在所有job之前执行的命令,包括发布job,但是在artifacts恢复之后。它可以是数组或者多行字符串。after_script被用来定义一些在所有job运行之后执行的命令,包括失败的那些。它必须是数组或者多行字符串。
    before_script和主 script在一个上下文/容器中运行。after_script是分离运行的,所以根据执行程序的不同,在工作树之外的改变可能不可见。比如:在before_script安装软件。
    它可以覆盖掉你在全局设置的before_scriptafter_script:

    before_script:
      - global before script
    
    job:
      before_script:
        - execute this instead of global before script
      script:
        - my commandling
      after_script:
        - execute this after my script
    
    

    stages

    stages被用来在全局定义可用的job.
    指定的stages允许拥有灵活的多个stage的pipelines。节点定义的顺序就是job执行的顺序:

    1. 在同一个stage中指定的job将会同时运行。
    2. 下一个stage将会在上一个stage完全成功后运行。

    让我们思考如下示例,它定义了三个stage:

    stages:
      - build
      - test
      - deploy
    
    
    1. 首先,在build中的所有job将会同时运行。
    2. 如果build中的所有job运行成功,则test中的所有job将会同时运行
    3. 如果build中的所有job运行成功,则deploy中的job将会同时运行。
    4. 如果deploy中的所有job运行成功,则commit将会标记为passed.
    5. 如果任何一个之前的job执行失败,则commit将会被标记为失败,并且之后stage中的所有job都不会执行。

    这里还有两个值得一提的边缘例子:

    1. 如果.gitlab-ci.yml中没有定义stages,这样的话默认情况下build, test,deploy 可以在job的stage中被使用。
    2. 如果job没有指定stage,那么job将被分配teststage.

    stage

    stage定义每一个job依赖的在全局stages中定义的stage.它允许一组job定义在不同的stage中,同一个stage中的job同时执行。比如:

    stages:
      - build
      - test
      - deploy
    
    job 1:
      stage: build
      script: make build dependencies
    
    job 2:
      stage: build
      script: make build artifacts
    
    job 3:
      stage: test
      script: make test
    
    job 4:
      stage: deploy
      script: make deploy
    
    

    types

    Deprecated: types已经被弃用了,并且可能会在未来的某个版本中移除,用stages代替

    script

    script是job中唯一一个必须要有的。这是一段Runner执行的shell脚本。比如:

    job:
      script: "bundle exec rspec"
    
    

    此参数还可以用数组包含一系列命令脚本:

    job:
      script:
        - uname -a
        - bundle exec rspec
    
    

    有些时候,script脚本可能需要用单引号或者双引号来包裹。比如:命令包含冒号(:)需要用引号包裹这样的化YAML解析器在解析的时候知道这是一个字符串而不是"key:value"这样的键值对。使用这些特殊字符串的时候要小心: :, {, }, [, ], , &, *, #, ?, |, -, <, >, =, !, %, @, , `.

    only 和 except (simplified)

    onlyexcept是用来设置job策略限时何时创建job的两个参数:

    1. only定义job运行的分支的名字,或者定义为tags(译者注:打tag的时候会运行)
    2. except定义不运行job的分支名称或者tags
      这里有一些规则适用于工作策略的使用:
    • onlyexcept都包括。如果onlyexcept在一个job中都被定义,ref将会被onlyexcept过滤。
    • onlyexcept允许使用常规表达式(使用Ruby regexp syntax).
    • onlyexcept允许指定仓库地址去过滤fork的仓库。
      另外,onlyexcept允许使用特殊的关键字:
    Value Description
    branched 当git refrence在pipeline中是一个分支的时候
    tag git refrence在pipeline中是一个tag的时候
    api 当pipeline被第二个pipeline触发的api(不是触发API)
    external 当使用的CI服务不是gitLab
    pipelines 对于多项目触发,创建使用有CI_JOB_TOKEN的API
    pushes 当用户使用git push的时候Pipeline触发
    schedules 看( scheduled pipelines)[https://docs.gitlab.com/ee/user/project/pipelines/schedules.html]

    triggers: 使用trigger token创建pipelines
    web|使用Gitlab UI上的Run pipeline创建pipeline(在你项目的Pipelines中)
    merge_requests|当merge request被创建或者更新的时候(看pipelines for merge requests

    在下面的例子中,job只会在以issue-开头的refs中运行,然而所有的分支将会被跳过

    job:
      # use regexp
      only:
        - /^issue-.*$/
      # use special keyword
      except:
        - branches
    
    

    在下面的例子中,job只会在被打过tag或者明确指定通过触发API请求构建或者Pipeline Schedule被的refs中被引用:

    job:
      # use special keywords
      only:
        - tags
        - triggers
        - schedules
    
    

    仓库地址能够被用来指定只有父仓库能够执行job而fork的不行:

    job:
      only:
        - branches@gitlab-org/gitlab-ce
      except:
        - master@gitlab-org/gitlab-ce
    
    

    上面的例子将会在gitlab-org/gitlab-ce的所有分支上运行job,而排除master分支
    如果job既没有only也没有except规则,默认设置为:only: ['branches', 'tags']
    比如:

    job:
      script: echo 'test'
    
    

    被翻译成:

    job:
      script: echo 'test'
      only: ['branches', 'tags']
    
    

    only 和 except (complex)

    refskubernetes策略在Gitlab10.0中被引入
    variables策略在10.7中被引用
    changes策略在11.4中被引入

    Warning:这是一个alpha的功能,它在任何时候都有可能在没有提前通知的情况下改变。

    从Gitlab10.0开始only/except job策略可以被定义的更加细致。
    Gitlab现在支持simple和complex两种策略,所以可以使用数组和哈希配置方案。
    四个键现在是有效的refs,kubernetes,variables,changes.

    refs 和 kubernetes

    Refs策略和简单模式下的only/except配置一样,而kubernetes策略和只接受active关键字。

    only:variables

    variables关键字被用来定义变量表达式。换句话说可以被用来与定义变量/项目/组或者环境范围变量去定义一个表达式Gitlab将会去评估,决定job是否需要被创建。
    看下面的例子。job只会在pipeline有scheduled或者运行的master分支,并且kubernetes在项目中是active的时候会被创建。

    job:
      only:
        refs:
          - master
          - schedules
        kubernetes: active
    
    

    变量表达式的例子:

    deploy:
      script: cap staging deploy
      only:
        refs:
          - branches
        variables:
          - $RELEASE == "staging"
          - $STAGING
    
    

    执行job依赖commit message的用例(在11.0中增加):

    end-to-end:
      script: rake test:end-to-end
      except:
        variables:
          - $CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/
    
    

    学习更多的变量表达式在另一个单独的页面

    only:changes

    only 或者except关键字使得根据git push的文件是否修改来判断job是否应该被创建成为可能。
    比如:

    docker build:
      script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
      only:
        changes:
          - Dockerfile
          - docker/scripts/*
          - dockerfiles/**/*
          - more_scripts/*.{rb,py,sh}
    
    

    在上面的例子中,如果你push 多个commit到GitLab现有的分支上,只要提供的commit中有一个包含以下改变,Gitlab将会创建并出发docker build:

    • Dockerfile文件
    • 任何在docker/scripts/文件夹下的文件
    • 任何在dockerfiles文件夹下面的文件或者子文件夹
    • 任何在more_scripts文件夹下以rb, py, sh为扩展名的文件

    Warning:在新的分支或者tags上面使用这个功能的时候,这里有一些注意事项,看一下面一个章节。

    在新的分支或者tags上面使用changes

    如果你push新的分支或者tag到Gitlab上面,这个策略将会总是被评估为true,并且Gitlab将会创建job.到目前为止,这个功能还没有于merge requests联系在一起,因为GitLab创建pipeline是在用户创建merge request之前,在这个时候我们无法知道目标分支是哪个。
    没有目标分支,不可能知道共同的祖先是谁,因此在这种情况下我们总是创建job.这个功能最好在稳定的分支上工作,因为在这中情况下Gitlab使用分支中上次commit的结果于这次push的SHA做比较。

    tags

    tags被用来从Runner列表中选择允许在这个项目中运行的Runner.
    在注册Runner期间你可以指定Runner的tag,比如ruby, postgres, development.
    tags允许你在job中运行指定的job:

    job:
      tags:
        - ruby
        - postgres
    
    

    在上面的例子中,我们确保job构建的Runner定义了rubypostgres的标签。
    Tags也是一个在不同的平台上运行不同job的好方法,比如给OSX Runner的tag赋值osx给Window Runner赋值windowstag,下面的job运行在各自的平台:

    windows job:
      stage:
        - build
      tags:
        - windows
      script:
        - echo Hello, %USERNAME%!
    
    osx job:
      stage:
        - build
      tags:
        - osx
      script:
        - echo "Hello, $USER!"
    

    相关文章

      网友评论

          本文标题:Gitlab CI 使用高级技巧

          本文链接:https://www.haomeiwen.com/subject/rxoghktx.html