美文网首页
GitLab CI with SBT/Maven build t

GitLab CI with SBT/Maven build t

作者: 墨弈 | 来源:发表于2018-03-20 14:08 被阅读0次

    Gitlab的CI工具比较好用,通常我们会把代码的push或者Tag标签的生成作为触发事件,启动代码的编译、测试和部署,这些都离不开Build tool的参与,而Gitlab-runner可以使用多种类型的Runner,或者将Build tools安装在本机,直接在Shell里边执行,或者采用Docker/Kubernetes类似的容器技术,配合Build tools的镜像执行编译操作,前者的问题在于每台机器都要进行编译工具的安装配置,扩容相对繁琐,每增加一个Runner都要自己在新的机器上进行一批操作,后者的好处显而易见只要是启动了Docker daemon的机器,都可以自动的pull对应的Build tool image来进行编译,减少了很多重复操作。

    在Docker镜像里边使用Sbt等编译工具需要考虑到每次编译所下载的依赖缓存到哪里,默认情况会放到对应的镜像运行时所对应的Container里边的目录,一旦镜像升级或者运行时的container被删除,所有的缓存的依赖在下次编译的时候都要重新下载,虽然可以通过Volumn挂载的方式将缓存产生在宿主机的某些目录,不过用这种方案依然避免不了在每个宿主机器上进行额外的缓存目录的配置,本文主要以SBT/Maven为例,说明如何在Gitlab CI工具中使用Docker类型的Runner来进行代码的编译,并且依赖GItlab CI的Cache功能来缓存编译时下载的各种依赖,加速重复编译的速度。

    关于如何构建SBT/Maven的镜像就不多说了,Docker hub上边有很多成熟的例子,基于Alpine Linux构造出来尽可能小的镜像即可。如何让每次Sbt镜像进行编译的时候能够重复的使用缓存,不需要重新下载依赖才是关键。

    1. SBT目录结构
    ls ~/.sbt
    0.13  1.0  boot  gpg  launchers  preloaded  repositories .credentials
    ls .sbt/1.0 
    build.sbt  plugins  server  staging  target  templates  zinc
    

    其中0.13和1.0对应不同大版本号的sbt.global.base目录,因为二者差别较大,boot对应sbt.boot.directory,repositories和.credentials是我们自己定义的仓库列表和所授权的用户名密码。
    sbt.global.base目录里边的内容不是那么纯粹,build.sbt以及plugins目录里边的*.sbt文件是我们预先配置好的插件和授权验证等信息,也包含了一些插件在update过程中所下载的依赖,因此这个目录的缓存是比较麻烦的,只能缓存其中一部分

    1. SBT缓存哪些数据
    • sbt 启动自身需要的依赖和插件等数据,比如我们每次修改buid.properties换一个更新的sbt版本号时可能就会触发的get sbt xxx version的提示
    • ivy cache and local,这部分是我们所编译的工程的依赖,默认路径是$HOME/.ivy2/{cache, local}
    • coursier cache, 如果我们使用了coursier来并行的解决依赖,也需要缓存这个插件的数据,默认位置是$HOME/.coursier/cache
    1. SBT项目.gitlab-ci.yml
    image: "xxxxx/sbt:1.1.0-alpine"
    
    variables:
      SBT_OPTS: "-Dsbt.global.base=/{absolute path}/sbt-cache/base -Dsbt.boot.directory=sbt-cache/boot -Dsbt.ivy.home=sbt-cache/ivy -Xmx3096m  -Dsbt.override.build.repos=true -Dsbt.repository.config=/root/.sbt/repositories" # 修改默认的路径,统一将sbt需要的东西都保存到某个sbt-cache目录,这个目录在下边的gitlab cache部分会定义
      # 注意sbt.global.base的路径只能是绝对路径,我们只能写具体的gitlab runner里边的build路径
      # 注意sbt.repository.config后边的路径也必须是绝对路径,如果用环境变量$HOME或者~替代,则会出现无法使用正确的仓库的问题
      COURSIER_CACHE: sbt-cache/coursier # 当使用Coursier时需要这一行,定义Coursier Cache
      SBT_CREDENTIALS: "/root/.sbt/.credentials" # 此处也是必须使用绝对路径,用$HOME环境变量无法找到正确的文件路径,这个环境变量主要在upgrade sbt的时候使用,如果不指定是无法使用私服去更新sbt的,此时没有开始加载basedir/credentials.sbt 这个文件,因此会报授权错误
    
    cache:
      #key: "$CI_BUILD_REF_NAME" # 每个分支一个缓存,还有其他的常量定义Tag等缓存的区分,默认是整个工程所有的Job都使用同一个缓存
      # 对于编译工具来说,不需要每个分支额外缓存一份,注释掉这行即可
      untracked: true
      paths:  #以下出现的路径都会在编译的时候由gitlab ci的runner负责创建和管理,只要相对路径即可,对应上边环境变量里边所设置的路径
        - "sbt-cache/ivy/cache"
        - "sbt-cache/ivy/local"
        - "sbt-cache/boot"
        - "sbt-cache/base"
        - "sbt-cache/coursier" #only needed if you use coursier
    
    before_script:
      - which sbt
      - mkdir -p sbt-cache/base/plugins 
      # 接下来比较奇怪,因为sbt的这两个路径里边不只有缓存的东西,还有一些我们预先配置好的脚本,比如plugin.sbt, build.sbt等,
      # 一般这些内容我们会直接打包到镜像里边,而缓存只有在第一次运行之后才会创建,如果不拷贝过去,因为上边的SBT_OPTS里边定义的路径都是缓存里边的路径,
      # 会导致我们配置的repositories和credentials不生效,如果不用上边的环境变量来修改,会导致有些内容不会被缓存,每次都会get sbt到临时的docker container中,重复下载
      - cp ~/.sbt/0.13/build.sbt sbt-cache/base/ # 根据情况0.13要改成1.0
      - cp ~/.sbt/0.13/plugins/*.sbt sbt-cache/base/plugins/ # 同上
    
    stages:
      - build
      - deploy
    
    compile:
      stage: build
      script:
        - sbt compile
      allow_failure: true
      tags:
        - sbt
    
    

    最终在执行完成后我们可以看到如下日志:

    ......
    HEAD is now at ddb6c5c  modified:   .gitlab-ci.yml
    Checking out ddb6c5c4 as docker_env...
    Skipping Git submodules setup
    Checking cache for default...
    Successfully extracted cache
    ......
    Creating cache default...
    sbt-cache/ivy/cache: found 528 matching files      
    WARNING: sbt-cache/ivy/local: no matching files    
    sbt-cache/boot: found 66 matching files            
    sbt-cache/base: found 174 matching files           
    sbt-cache/coursier: found 9544 matching files      
    untracked: found 17215 files                       
    Created cache
    Job succeeded
    

    能够看到缓存在各个目录的文件的情况

    1. Maven目录结构
      Maven相对来说要简单很多,我们只要缓存.m2/repository就可以了
    2. Maven工程的.gitlab-ci.yml
    image: "xxxxx/tools/maven:3.3.9-alpine"
    
    variables:
      MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
    
    cache:
      untracked: true
      paths:
        - .m2/repository
    
    ......
    
    

    相关文章

      网友评论

          本文标题:GitLab CI with SBT/Maven build t

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