.gitlab-ci.yml Gitlab CI 简单配置

Gitlab

原文发表在个人博客: Level Up

最近离职，一张机票跨越小半个中国，来魔都找了一份喜欢的工做。稳定了就开始继续写东西啦 👯‍

毕业实习的时候在公司里面积极推 Git，考虑到同事的学习成本，在 Gogs 和 Gitlab 之间，我选了 Gogs，不为别的，只为原生中文 😂。而后一大段时间，我都是在 Github 和 Gogs 这两个平台进行协做的，Gitlab 的大名也不时的在耳边响起。

如今的公司版本控制用的是 Gitlab，因此借此机会我也简单适应了一下，其实和 Github 差不太多，更多的是 Gitlab 提供了一整套的解决方案，其中就包含了 CI/CD。

我仍是比较崇尚那句话的：一切能自动化的工做都应该被自动化掉！

.gitlab-ci.yml

在 Gitlab 官网上有不少关于 gitlab CI 如何搭建的介绍，在此我就很少作介绍了，就是照着代码敲到命令行执行便可，如今要讲的是如何配置一个简单的 Gitlab CI 配置文件。

.gitlab-ci.yml 这个文件便是 Gitlab CI 的配置文件，你须要将这个文件放到你 repo 的根目录便可，而后你每次提交， Gitlab 都会自动地去读取执行该文件的内容，若是你提交了一个新的 .gitlab-ci.yml，那 gitlab CI 会使用你刚提交的那份配置文件进行 CI

下面就贴一份简单的用于部署前端项目的 .gitlab-ci.yml 文件:

# 这个是我如今项目初期使用的一个配置文件
# 下面我就开始简单的讲一下各个配置的做用
# yml 文件支持注释，像当前文字这样，左侧以 # 号开头即为注释

# 下面这个是表示，咱们运行 CI 用的镜像是 kkarczmarczyk/node-yarn:latest
# 由于我司的 CI 任务是选的在 Docker 上运行，因此每次执行 CI 任务的时候，都会新启动一个 Docker 容器
# 而后在容器中依次执行下面的命令
# 注意：不一样的 stage 执行前，都会将该容器环境设置为初始化时的状态
image: kkarczmarczyk/node-yarn:latest

# 定义全局的缓存策略，如上所说，每一个不一样的 stage，CI 都会从新启动一个新的容器，因此咱们以前 stage 中的文件都会消失
# 那在前端开发中，就意味着每一个 stage 都要从新完整装一次 node_modules，这样的时间和网络成本都不低
# 因此咱们选择将这些文件缓存下来
# 可是，缓存也要讲究实效性，例如我在第二次的提交中增长了一个库，那第二次的 CI 就不能再重复使用上一次的 node_modules 缓存了
# 在 .gitlab-ci.yml 中，咱们经过设置 cache 的 key 来区分不一样的缓存
cache:
  # 该 Key 的值为一个系统变量，gitlab 在运行的时候内置了很多的系统变量供使用，下面的配置表示
  # 以每次提交的 ref 号为 key 来区分不一样缓存，效果就是同一次提交中的全部 stage 用同一份 cache
  key: ${CI_COMMIT_REF_SLUG}

# 定义 stage，stage 能够简单的理解为“步骤”，会顺序执行，若是上一步错了，那不会继续执行下一步
# 好比像下面我定义的，第一步先初始化，第二步检查代码规范，第三步进行单元测试，第四步构建，第五步就直接将项目部署到服务器
stages:
  - init
  - lint
  - unit_test
  - build
  - deploy

# 这个是某个任务的名称，你能够随意起名
install_packages:
  # 指定该任务所属的步骤，每到一个步骤，该步骤所对应的全部任务都会并行执行
  stage: init
  # 指定要缓存的文件以及文件夹
  cache:
    # 这个属性是 gitlab 比较新版本里面加的特性，意思是在这一步，我只上传这个缓存，我不会拉取该缓存
    policy: push
    # 指定缓存的内容，在下面我缓存了 node_modules 这个文件夹，你还能够在下面继续添加文件或者文件夹
    paths:
      - node_modules/
  # 该任务要运行的脚本，顺序执行
  # 都是 bash 命令
  # 默认当前目录就是 repo 的根目录
  script:
    # 我先列出全部文件的列表，便于 script 出错后进行调试
    - "ls -la"
    # 设置 yarn 的源，会快一些
    - 'yarn config set registry "https://registry.npm.taobao.org"'
    # 安装全部依赖，也就是 node_modules
    - "yarn"

# 执行完 init 这个 stage（步骤）后，咱们的 node_modules 目录就缓存下来了
# 而后咱们就开始执行代码检查
lint_code:
  # 对应的步骤是代码检查，能够多个任务指向同一个 stage，这些任务将会被并行执行
  stage: lint
  # 定义缓存
  cache:
    # 下面的配置指示，咱们当前只拉取缓存，不上传，这样会节省很多时间
    policy: pull
    # 指定要缓存的文件/文件夹
    paths:
      - node_modules/
  # 该任务要运行的 bash 脚本
  script:
    - "ls -la"
    - "yarn lint"

# 单元测试
unit_test:
  # 隶属于 单元测试 这个步骤
  stage: unit_test
  # 同 lint_code 任务，拉取缓存，咱们就不用再从新下载 node_modules 了
  cache:
    policy: pull
    paths:
      - node_modules/
  # 执行 bash 命令
  script:
    - "ls -la"
    - "yarn test:unit"

build:
  stage: build
  cache:
    policy: pull
    paths:
      - node_modules/
  # artifacets 是打包你指定的文件或者文件夹，而后你能够经过 gitlab 的页面进行下载的
  artifacts:
    # artifacets 的名字
    name: "dist"
    # artifacets 的过时时间，由于这些数据都是直接保存在 Gitlab 机器上的，过于久远的资源就能够删除掉了
    expire_in: 60 mins
    # 制定须要打包的目录，这里我把 dist 目录给打包了，准备发布到服务器
    paths:
      - dist/
  script:
    - "ls -la"
    - "yarn build"

# 部署任务
deploy:
  stage: deploy
  # 该命令指定只有 master 分支才可以执行当前任务
  only:
    - master
  # 部署脚本，在下面的代码中，我用到了不少相似 ${AMAZON_PEM} 的变量，因为咱们的私钥、Ip 都算是不宜公开显示的信息，
  # 因此我用到了 Gitlab 的变量工具，在 repo 的 Setting > CI/CD > Secret variables 中，这些变量值只有项目管理员才有权限访问
  script:
    - "ls -la"
    - "ls -Rl dist"
    - 'echo "${AMAZON_PEM}" > amazon.pem'
    - "chmod 600 amazon.pem"
    - "scp -o StrictHostKeyChecking=no -i amazon.pem -r dist/* ${AMAZON_NAME_IP}:/usr/share/nginx/html/"

坑 s

在使用的过程当中，仍是经历了一些坑的，也记录下来

• 公司的 Gitlab 估计是版本问题，cache 基本是失效的，因此无奈，我直接添加了一个 before_script 来在每一个 jobs 执行前都完整安装一次 node_modules
• 将服务器私钥保存到 Gitlab 的 CI 变量中后，本想经过 echo ${AMAZON_PEM} > amazon.pem，把私钥存储为文件使用，结果发现 echo 出来的文本没有了换行，最终解决办法是 echo "${AMAZON_PEM}" > amazon.pem（就只须要加两个引号）

原文发表在个人博客: Level Up