Hello大家好，我是日拱一卒的不浪，坚持从工作和生活中不断学习，提炼，沉淀，最终建立自己的强势领域！这是2024年输出的第3/100篇文章，欢迎志同道合的朋友一起学习交流；

公众号：攻城师不浪
wx：brown_7778

这是该系列文章的下半部分，如果你没有看上一篇且不了解相关知识的话，强烈建议先看上一篇；
【保姆级教学】内网部署的gitlab，如何通过CI/CD自动构建打包部署私有npm包（上）

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

一共分两大部分：

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

配置文件

.gitlab-ci.yml脚本文件

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

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

具体代码：

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

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

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

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

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

运行平台Runners

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

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很贴心的给我提供了操作流程

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

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

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

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

替换两处：

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

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

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

执行激活命令：

sudo gitlab-runner verify

查看执行结果：

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

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

大功告成！

总结

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

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

如果觉得文章对你有帮助，欢迎点赞关注以及收藏，这也是支持我持续创作下去的动力~

点击关注不迷路，持续升级打怪