CI/CD

OpenCode 是一个面向终端的 AI 编程工具，支持配置多个模型 Provider，并可以在不同模型之间进行切换。

如果手上有 SenseNova Token Plan Token，可以直接将 SenseNova 配置到 OpenCode 中使用。目前SenseNova处于公测期间，完全免费试用，可以上手一试。

本文记录完整配置过程，并给出一份实际验证可用的 opencode.json 配置。

一、整体方案

OpenCode 支持通过 OpenAI-compatible 接口接入第三方模型。

SenseNova Token Plan 提供了兼容 OpenAI API 风格的接口，因此不需要额外搭建一个 OpenAI-compatible 服务，可以直接从 OpenCode 请求 SenseNova。

整体调用链路如下：

┌─────────────────────┐
│       OpenCode      │
│     AI 编程工具      │
└──────────┬──────────┘
           │
           │ OpenAI-compatible API
           ▼
┌─────────────────────┐
│ SenseNova Token Plan│
│ token.sensenova.cn  │
└──────────┬──────────┘
           │
           ├── SenseNova 6.8 Flash Lite
           │
           └── DeepSeek V4 Pro

核心配置实际上只有三个部分：

博客内容有一年时间没有更新了，不是不想更，而是没法更。

去年更换电脑以后，重新安装了hugo导致本地跑不起来，搞了好久也没搞定。期间也有重试修复过两次还是没跑起来，就一直搁置了下来。

最近下定决心完全从零开始学习的方式安装hugo和主题，修改配置才终于重新跑了起来。

总结下原因：

换电脑以后直接安装了最新版hugo，而主题没有更新，或者是主题也更新了但是与主题相关的项目配置还是旧的，然后就是各种出错。现在是直接复制出了主题中的示例项目中的配置才正确的跑了起来。

gitlab ci/cd 中，需要使用到 docker registry 账号 push 镜像，这个可以设置为机器人，可以避免个人账号泄露

配置Harbor机器人

登录 Harbor 管理界面，进入系统管理→认证页面；
选择机器人 Token页签，点击左上角的新建机器人，创建一个名为gitlab-ci的机器人；
给该机器人一个名称，并给该机器人添加相应的权限；
机器人创建完成以后，点击右侧的查看token来复制该机器人的 token，这个就是以后用 gitlab-ci 配置文件使用的账号密码；
在gitlab 创建 harbor-robot 用户；
为该用户添加项目级别的 开发 权限；

配置gitlab-ci

在项目的设置中添加 docker registry 账号密码，仓库地址是harbor的；
编辑.gitlab-ci.yml文件，把账号密码改为之前复制的 token；

注意点

有些情况下创建的机器人账户会带上$符号，在gitlab中是无法使用的，需要将$改为两个$$来表示$；

结束

这样gitlab-ci 就可以顺利跑测试、构建、推送镜像了；

以上内容，只是简单的配了配 harbor，可以有很多其他方法完成该工作，这里只是简单的记录下而已；

如果需要复杂的设置，欢迎移步harbor 文档，那里有更多的内容可以提供参考。

如果你打算搭建一套发布系统，你可能会考虑jenkins，或者其他。我要介绍的则是一些现成的，使用更简单的工具。没用特殊环境要求的情况下则完全可以代替jenkins。

GitHub Actions
gitlab ci
阿里云流水线
coding持续部署

上面只是列举了四类，实际上你会发现市面上的云服务商和代码仓库都提供了类似的工具，虽然有些是收费的，但是也有不少免费的，对于个人来说其实大多数都是够用了。

tsconfig.json 中 exclude node_modules，但 tsc 还是报错。

node_modules/connect-mongo/src/types.d.ts:113:66 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'.

113         get: (sid: string, callback: (err: any, session: Express.SessionData | null) => void) => void;                                                                     ~~~~~~~~~~~

node_modules/connect-mongo/src/types.d.ts:114:45 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'.

114         set: (sid: string, session: Express.SessionData, callback?: (err: any) => void) => void;
                                                ~~~~~~~~~~~

node_modules/connect-mongo/src/types.d.ts:118:47 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'.

118         touch: (sid: string, session: Express.SessionData, callback?: (err: any) => void) => void;

另一种解决方案：

去年花了三天时间开发了一个简易版的nodejs发布系统，它是基于pm2自带的deploy机制开发的，主要原理就是在两台装有pm2的机器直接通信，并执行相应的命令。再往简单了说就是在发布机上远程执行命令，而朱雀发布系统提供了一个图形界面而已。

当时把这个系统定位为nodejs专用发布系统，因为它依赖了pm2，而pm2则是nodejs专用的进程管理工具，其他语言用不到。这个系统的上线也算是解决了我司一直以来没有合适的nodejs发布系统的空缺。

经过9个月的使用，也算比较稳定。但是也存在问题，最大的问题是部署应用方面比较繁琐。

基本流程如下：

发布机和应用服务器设置ssh通信配置。
应用服务器安装git（有自带，但是版本太旧）。
配置git用户名，邮箱。
生成ssh公钥。
把应用服务器的公钥配置到git代码服务器上。以便能拉代码。
发布机远程执行git pull来代码操作，各应用服务把代码拉取下来。
执行编译打包操作。
执行重启服务操作。

部署一次系统还是比较麻烦的，如果应用服务器有多台，可能还要重复这样的操作多次，实在比较麻烦。

使用scp同步代码的方式会比较简单一些，但是像nodejs这样的项目，node_module占了很大比重，如果每次都打包的话会拖慢同步速度，而scp又不具备排除文件夹的能力。

最后找到了rsync命令可以满足需求。然后就是基于rsync实现了一版。不用再依赖pm2，应用服务器也不用强制使用git了。

朱雀发布系统

朱雀和Jenkins对比如何？

要说Jenkins那绝对是持续集成领域的老大哥，自然是功能强大。但是每个团队和产品有其特殊性，Jenkins并不完全适用。而朱雀也有其优势。

朱雀本身部署简单，使用go开发，不依赖运行时，无需安装，开箱即用。
目前支持和测试过的数据库有sqlite3（目前用的，不需要繁琐的安装过程）和mysql。
配置简单。
部署发布一键完成，不需要单独的部署过程。
并行发布。
审批，通知，权限。
开源，可定制开发。

项目地址：朱雀发布系统

Nodejs项目部署到服务器以后接下来做的最多的操作就是上线发布了。因为nodejs的语言特性决定了其开发效率高，发布自然就频繁，每个公司或个人都有自己的发布方式。

有的公司会有严格的流程，必须通过CI/CD工具进行发布，有可能使用现成的工具，如：jenkins。有可能是自研发布系统。

有的公司会通过FTP上传代码到服务器发布。

有的公司使用更原始的发布方式，直接登录服务拉代码发布。

不论哪种发布方式都有其优缺点，越高级的工具会有诸多限制，比如有权限控制，有严格的审批流程，自然就不能随时发布，也就越僵化。越原始的方式越简单越灵活，自然风险也越高。

至于采用哪种发布方式，依据需要选择即可。

而关于nodejs的发布方式，本人也是也是多种方式都有使用，公司项目也经历过多次变迁。公司最开始是直接登录服务器拉代码发布，后来有了运维团队，领导说开发自己发布不安全，于是就由运维搭建了Jenkins环境来发布，但是每次发布都需要走流程，后来因为发布太频繁，每1-2天要发布一次，又要灰度发布，运维也会觉得烦。于是开发就搭建了某个发布系统自己来发布，不过这个发布系统有个缺点，就是发布集群的时候是串行的，每次发布要十几分钟。

另外说明一下Jenkins。它应该是使用最多的发布系统了，Jenkins基于Java开发，它已经是成熟的系统了，成熟同时也代表着复杂，复杂代表修改困难，我想大家也不太会基于Jenkins定制开发。然后是部署困难，相比较nodejs三条命令搞定linux安装nodejs——快捷版，go直接放二进制文件部署，Jenkins部署可能就略显复杂了。

于是下定决心自己开发一个发布系统，朱雀发布系统因此诞生。

基于以往的发布系统使用经历，我想要的是一款使用够灵活，部署够简单的发布系统。市面上现有的系统为了满足各种语言的发布，做的大而全。我自然是不想重蹈覆辙再做一个大而全的系统，我要的是小而美。正好之前了解过PM2本身集成了远程发布功能，可以在此基础上开发。PM2本身的发布过程其实已经很简单了，而且足够灵活，能够满足我的部分要求，但是公司的环境是不能在本地直接连接应用服务器的，所以需要一个中间层代理一下，放一张简单的架构图：

架构图

和其他工具架构逻辑一样，都是通过ssh来通信，不同的是朱雀没有直接使用ssh，而是利用了pm2,由pm2来实现通信，它已经为了做了一部分工作，比如拉代码，回滚，执行远程脚本。由于nodejs的项目特性，它依赖了node_modules包，如果按照打包的方式发布会又大又费时，所以还是选择拉git代码的方式发布比较合适。所以我只需要给它做一个图形界面，并有一定的管理和审批流程（可根据环境跳过）。放一张图来看一下：

朱雀发布系统