书接上回，在上一篇文章中我们已经介绍了如何用命令行手动部署私有npm包，那么接下来我将继续为大家介绍如何在gitlab中全自动部署你的私有npm包。

一共分两大部分：

  • 自动化配置文件脚本
  • 执行自动化所依赖的软件Runner

配置文件

.gitlab-ci.yml脚本文件

在项目的根目录下新建.gitlab-ci.yml，通过它去控制我们整个自动化的流程，当你的项目中有这个文件时，每次你提交代码后，gitlab会自动扫描并开始执行自动化流程。(注：文件名称一定要打对，我一开始就吃了这个亏，然后一直纳闷为啥gitlab自动化不执行😂)

gitlab可以发布release文件吗_gitlab

接下来我们给上篇文章提到的uefe-api这个库添加一个配置文件

gitlab可以发布release文件吗_git_02

具体代码：

stages: # 流水线节点
  - install
  - build
  - deploy

cache: # 缓存
  paths:
    - node_modules
    - build

install-job:
  tags:
    - uefeapi
  stage: install
  script:
    - npm install -f

build-job:
  tags:
    - uefeapi
  stage: build
  script:
    - npm run build

deploy-job:
  tags:
    - uefeapi
  stage: deploy
  script:
    - npm publish
    - echo "-- build completed succesfully"

首先需要先了解下yml文件的语法

  • stages: 定义在最外层，它的值相当于一个数组，用来定义流水线中有多少个节点，这些节点我们也叫它Job，可以看出我这个项目一共3个job，他们各自分工；
  • cache: 缓存，将之前工作后的不变的文件进行缓存，提高效率；
  • install-job：节点名称，可以自己按照节点功能去自定义；
  • tags： 当前Job的标记，这个很重要，因为Runner会根据tags去判断是否执行当前Job（后边讲在如何定义这个tags）；
  • stage： 表示当前执行的是哪个Job，是stages的一个子项；
  • script: 当前节点运行的shell脚本命令，也就是说在这个节点我们需要执行什么命令，都是通过它来控制的；

那么我这个项目一共就是执行3步：

  • 安装依赖
  • 打包文件
  • 发布

npm配置文件（.npmrc）

当执行到publish的时候，npm需要身份验证，在上节课我们是通过命令行去配置的npm（如果没看上一篇的去看下），这节课我们需要在该项目的npm配置文件.npmrc中去配置发布需要的Deploy Token（上一篇结果如何获取），配置文件里暂且定义为AUTH_TOKEN

# Set URL for your scoped packages.
@hnc:registry=http://gitlab.com/api/v4/packages/npm/


# # Add token for uploading to the registry. Replace <your_project_id>
# # //gitlab.com/api/v4/projects/<your_project_id>/packages/npm/:_authToken=${AUTH_TOKEN}

//gitlab.com/api/v4/projects/133/packages/npm/:_authToken=${AUTH_TOKEN}

注意替换字段：

  • @hnc：替换成自己的项目scope（上一篇文章讲过）；
  • gitlab.com: 替换成自己的gitlab网站域名；
  • 133：替换成你项目的id（上一篇文章讲过）；

注意：这时候有的同学会问，这个AUTH_TOKEN不用替换吗？

答：需要替换，但不是在配置文件里明文替换！那在哪里配置啊？（这也是坑了我好几个小时的问题😭）

前人栽树后人乘凉，我直接告诉你（不用谢！）

gitlab可以发布release文件吗_ci/cd_03

这里gitlab支持添加一些私密性的变量，当你添加了之后，执行gitlab-ci.yml脚本的时候会自动读取到这个变量！

注意：这个.npmrc一定要配置正确，特别是这个token，它是跟CI脚本配合执行的，不然在publish阶段会一直提示身份验证不通过等字眼。

当我配置完成之后将代码push到gitlab，激动的搓了搓小手，等待它全自动化完成部署，然后等着老板的夸我~ 然而现实却给了我一个大逼斗😭

gitlab可以发布release文件吗_git_04

这是什么鬼，我在这足足等了你十分钟，你就愣是一动不动，一直pending状态；

然后我就去网上一顿查，原来，这才只是完成了第一步啊，也就是我们这个脚本文件没人来给我们执行，这就相当于厨子做好了饭，但是没有服务员给我们端过来一样一样滴~

运行平台Runners

定义： gitlab自动化执行，需要依赖一个软件机制，就是这个Runners

gitlab可以发布release文件吗_ci/cd_05

gitlab提供了两种Runners

  • Specific Runner： 运行在个人电脑端的程序，相当于本地运行，需要先下载下来再运行；
  • Shared Runner： gitlab提供的免费runner程序，相当于云上运行，这个需要具有gitlab管理员权限的人去配置；

区别：

  1. Shared Runner适用于你gitlab中的所有项目，而Specific Runner只针对指定项目运行；
  2. 私人项目Shared Runner具有时间限制，而Specific Runner无上限，随便使用；

这篇文章我们将使用Specific Runner作为教学，首先我们需要将gitlab-runner下载到本地，gitlab很贴心的给我提供了操作流程

gitlab可以发布release文件吗_git_06

打开之后，提供了适配各种系统的runner，选一个适配你系统的进行下载运行，例如我用macos举例，直接在命令行里进行操作即可：

gitlab可以发布release文件吗_npm_07

按照上边的步骤操作完之后，出现以下字样就算启动runner成功了

gitlab可以发布release文件吗_前端_08

启动成功之后，我们需要将这个runner与我们的项目进行绑定，这时执行

sudo gitlab-runner register --url gilab域名 --registration-token $REGISTRATION_TOKEN

替换两处：

  • gitlab域名：替换成自己的内网gitlab域名
  • $REGISTRATION_TOKEN：替换成gitlab给我们的那个token，看下边这张图片

gitlab可以发布release文件吗_前端_09

执行命令过后会让你做一些参数选择，如下：

gitlab可以发布release文件吗_gitlab_10

以上我们就把runner与项目进行绑定成功了，细心的同学会发现我们的runner前边有一个灰色叹号，这是还没有激活runner的原因

gitlab可以发布release文件吗_ci/cd_11

执行激活命令：

sudo gitlab-runner verify

查看执行结果：

gitlab可以发布release文件吗_git_12

这时候再刷新一下页面，激活成功！

gitlab可以发布release文件吗_npm_13

这时候我们再去看一下CI/CD执行的情况，如果未执行，可点击主动执行：

gitlab可以发布release文件吗_ci/cd_14

大功告成！

总结

以上，就是我们通过CI/CD自动构建打包部署私有npm包（下）的全部内容，也是我反反复复执行了50多次脚本总结出来的成果😭

  • 构建.gitlab-ci.yml脚本
  • 配置.npmrc
  • 下载Runner并注册运行