修复 Insomnia inso CLI 的 test-cli.yml CI 失败本地复现步骤与 Node/Electron 运行时差异【免费下载链接】insomniaThe open-source, cross-platform API client for GraphQL, REST, WebSockets, SSE and gRPC. With Cloud, Local and Git storage.项目地址: https://gitcode.com/GitHub_Trending/in/insomnia本篇围绕 Insomnia 仓库中Test CLIGitHub Actions 工作流的本地故障定位方法展开核心是文档 fix-test-cli-ci 技能指南 所定义的排查流程。读完你将掌握如何在本地完整复现inso命令行的test:bundle/test:binary两条测试路径如何区分 Node.js 与 Electron 两套原生 libcurl 二进制的安装时机以及如何按常见失败模式快速定位getinsomnia/node-libcurl加载失败、smoke-test 服务未启动、打包产物缺失等问题。一、Test CLI工作流测试了什么CI 侧的入口是 .github/workflows/test-cli.yml它在ubuntu-24.04上运行由merge_group、push到develop、pull_requestopened/synchronize三种事件触发超时上限 10 分钟。工作流的关键步骤依次为npm ci安装全部 workspace 依赖Node 版本由.nvmrc指定当前为24.18.0npm run install-libcurl-node——为 CLI 测试安装 Node 目标版本的 node-libcurl这一步是本地复现时最容易被遗漏的前置条件npm run build -w insomnia-inso生成dist随后npm run test:unit -w insomnia-inso跑单元测试npm run serve -w insomnia-smoke-test npx -y wait-on http://localhost:4010启动 smoke-test 服务并阻塞等待端口就绪npm run test:bundle -w insomnia-inso跑 bundle e2e 测试再用yao-pkg/pkg把 CLI 打包为binaries/inso执行npm run test:binary -w insomnia-inso验证打包后的二进制最后npm run artifacts产出 zip/tar/gz 并上传为 workflow artifact。本地复现的难点在于CI 是“一条流水线串起 Node 依赖、bundle、打包、二进制”四段而本地开发环境默认装的是 Electron 目标的原生模块两段测试路径bundle 与 binary对产物形态的要求也不同。这正是文档 SKILL.md 要解决的定位场景。二、本地复现的六步标准流程按 SKILL.md 的定义在拿到 CI 日志后先做两件事确认失败发生在test:bundle、打包二进制运行、还是测试前的构建/打包阶段记下失败用例名和第一条可操作的错误信息。然后在仓库根目录执行第 1 步安装 Node 目标的 libcurl而非 Electron 变体npm run install-libcurl-node该命令在根 package.json 中定义本质是用node-pre-gyp针对node_modules/getinsomnia/node-libcurl拉取--runtimenode --target24.18.0的预编译二进制install-libcurl-node: node-pre-gyp install --directory node_modules/getinsomnia/node-libcurl --update-binary --runtimenode --target24.18.0第 2 步构建insomnia-inso生成distnpm run build -w insomnia-inso对应 packages/insomnia-inso/package.json 中的build: esr esbuild.ts。esbuild 配置见 esbuild.tsplatform: node、target: node22、输出 CJS 到./dist/index.js且把getinsomnia/node-libcurl声明为external不进 bundle运行时从node_modules动态加载原生二进制——这就是为什么第 1 步装错运行时会导致加载失败。第 3 步启动 CLI 测试依赖的 smoke-test 服务npm run serve -w insomnia-smoke-test该脚本在 packages/insomnia-smoke-test/package.json 中定义为serve: esr server/index.ts服务监听端口固定为 4010见 server/index.ts 第 45 行const port 4010;。CI 中用wait-on http://localhost:4010等待端口就绪本地则保持该终端常开。第 4 步在另一个终端跑 bundle 测试套件npm run test:bundle -w insomnia-insopackages/insomnia-inso/package.json 中该脚本为vitest cli.test.ts -t inso dev bundle即只执行 cli.test.ts 中名为inso dev bundle的describe块。第 5 步若 CI 失败点在打包二进制路径或 bundle 测试本地已全绿再跑 binary 测试npm run test:binary -w insomnia-inso脚本为vitest cli.test.ts -t inso packaged binary它执行同一套命令断言但把被测对象从bin/inso经由 esbuild 产出的开发入口替换为binaries/insonpm run package -w insomnia-inso由yao-pkg/pkg打包出的可执行文件见 package.json 的package: npx -y yao-pkg/pkg6.14.1 . --output binaries/inso --targets host。第 6 步收尾Teardown验证完成后停掉npm run serve -w insomnia-smoke-test进程重新安装 Electron 目标的 libcurl避免影响后续 Electron 开发npm run install-libcurl-electron根 package.json 中对应--runtimeelectron --target43.2.0。注意根目录的postinstall钩子默认执行的就是install-libcurl-electronpatch-package npm run verify-bundle-plugins -w insomnia npm run install-libcurl-electron所以任何一次npm ci之后本地环境都会回到 Electron 二进制状态需要重跑test:bundle时必须重新执行第 1 步。三、核心原理为什么 Node 与 Electron 二进制不兼容insomnia-inso的请求发送最终依赖getinsomnia/node-libcurl这个原生 Node 模块。Electron 与 Node 各自编译的 ABI即NODE_MODULE_VERSION不同node-pre-gyp的--target参数决定了预编译二进制绑定到哪一侧运行时install-libcurl-node--runtimenode --target24.18.0供inso在纯 Node 环境bundle 测试、inso用户中加载install-libcurl-electron--runtimeelectron --target43.2.0供桌面 App 开发使用。加载错版本时典型报错就是NODE_MODULE_VERSION不匹配、dlopen失败或原生模块加载异常。这也是 SKILL.md “Common failure patterns” 第一条的依据凡错误信息里出现getinsomnia/node-libcurl、NODE_MODULE_VERSION、dlopen或原生模块加载字样优先怀疑 libcurl 二进制与当前运行时不匹配用npm run install-libcurl-node重装即可。从源码结构看这条链路的其余环节同样依赖 Node 侧esbuild.ts 把platform设为node并将.renderer后缀的模块重定向到.node变体rendererToNodePlugin进一步说明 inso 是一个纯 Node 构建产物与 Electron 渲染进程隔离。四、常见失败模式速查SKILL.md 归纳了三类高频故障结合测试源码可以给出更精确的判别位置症状根因处理getinsomnia/node-libcurl/NODE_MODULE_VERSION/dlopen/ 原生模块加载错误libcurl 二进制是 Electron 目标版本或版本漂移npm run install-libcurl-node重装后重跑连接http://localhost:4010失败smoke-test 服务未启动。测试入口 cli.test.ts 的beforeAll会先fetch(http://localhost:4010)探活探活失败整个套件直接报错保持npm run serve -w insomnia-smoke-test常驻缺少dist输出或缺少binaries/insonpm run build -w insomnia-inso或npm run package -w insomnia-inso未执行/失败重新执行对应构建或打包步骤prepackage会先build:production并清理旧binaries/inso补充两个便于定位的细节bundle 与 binary 两条路径复用同一份命令断言。cli.test.ts 用shouldReturnSuccessCode/shouldReturnErrorCode两个命令列表覆盖lint spec、export spec、run test、run collection含鉴权、正则过滤、after-response 脚本、环境变量覆盖、超时、客户端证书等场景断言退出码为 0 或 1inso packaged binary块则把同一列表中的bin/inso批量替换为binaries/inso再跑一遍。因此 CI 日志里如果只有打包路径失败、bundle 路径全绿问题大概率出在pkg打包阶段如kong资源的pkg.scripts打包规则而不是 CLI 逻辑本身。部分用例还会校验 verbose 输出内容如console log appears in timeline断言HTTP/1.1 200 OK、foo bar baz这些请求打到http://127.0.0.1:4010/的 echo 端点进一步印证 smoke-test 服务是这些断言的硬依赖。五、成功判据SKILL.md 给出的验收标准是npm run test:bundle -w insomnia-inso正常退出exit 0Vitest 报告inso dev bundle用例全部通过若同时验证打包二进制路径npm run test:binary -w insomnia-inso也正常退出。两条判据分别对应 CI 中Run Inso bundle e2e tests与Run Inso binary e2e tests两个步骤本地全绿即可视为对该test-cli.yml失败的修复完成若仍需验证产物可参照 CI 的artifacts步骤在本地执行npm run artifacts -w insomnia-inso生成压缩包自查。附适用前提与限制流程基于当前仓库的 Node24.18.0.nvmrc为24.18.0、npm11环境见根 package.json 的engines字段install-libcurl-node的--target24.18.0与install-libcurl-electron的--target43.2.0均写死在根package.json脚本中若升级 Node 或 Electron 版本需同步更新这两个 target 才能拉取匹配的预编译二进制本文仅说明查看、安装与运行方式不涉及对仓库内容的修改。【免费下载链接】insomniaThe open-source, cross-platform API client for GraphQL, REST, WebSockets, SSE and gRPC. With Cloud, Local and Git storage.项目地址: https://gitcode.com/GitHub_Trending/in/insomnia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
修复 Insomnia inso CLI 的 test-cli.yml CI 失败：本地复现步骤与 Node/Electron 运行时差异
修复 Insomnia inso CLI 的 test-cli.yml CI 失败本地复现步骤与 Node/Electron 运行时差异【免费下载链接】insomniaThe open-source, cross-platform API client for GraphQL, REST, WebSockets, SSE and gRPC. With Cloud, Local and Git storage.项目地址: https://gitcode.com/GitHub_Trending/in/insomnia本篇围绕 Insomnia 仓库中Test CLIGitHub Actions 工作流的本地故障定位方法展开核心是文档 fix-test-cli-ci 技能指南 所定义的排查流程。读完你将掌握如何在本地完整复现inso命令行的test:bundle/test:binary两条测试路径如何区分 Node.js 与 Electron 两套原生 libcurl 二进制的安装时机以及如何按常见失败模式快速定位getinsomnia/node-libcurl加载失败、smoke-test 服务未启动、打包产物缺失等问题。一、Test CLI工作流测试了什么CI 侧的入口是 .github/workflows/test-cli.yml它在ubuntu-24.04上运行由merge_group、push到develop、pull_requestopened/synchronize三种事件触发超时上限 10 分钟。工作流的关键步骤依次为npm ci安装全部 workspace 依赖Node 版本由.nvmrc指定当前为24.18.0npm run install-libcurl-node——为 CLI 测试安装 Node 目标版本的 node-libcurl这一步是本地复现时最容易被遗漏的前置条件npm run build -w insomnia-inso生成dist随后npm run test:unit -w insomnia-inso跑单元测试npm run serve -w insomnia-smoke-test npx -y wait-on http://localhost:4010启动 smoke-test 服务并阻塞等待端口就绪npm run test:bundle -w insomnia-inso跑 bundle e2e 测试再用yao-pkg/pkg把 CLI 打包为binaries/inso执行npm run test:binary -w insomnia-inso验证打包后的二进制最后npm run artifacts产出 zip/tar/gz 并上传为 workflow artifact。本地复现的难点在于CI 是“一条流水线串起 Node 依赖、bundle、打包、二进制”四段而本地开发环境默认装的是 Electron 目标的原生模块两段测试路径bundle 与 binary对产物形态的要求也不同。这正是文档 SKILL.md 要解决的定位场景。二、本地复现的六步标准流程按 SKILL.md 的定义在拿到 CI 日志后先做两件事确认失败发生在test:bundle、打包二进制运行、还是测试前的构建/打包阶段记下失败用例名和第一条可操作的错误信息。然后在仓库根目录执行第 1 步安装 Node 目标的 libcurl而非 Electron 变体npm run install-libcurl-node该命令在根 package.json 中定义本质是用node-pre-gyp针对node_modules/getinsomnia/node-libcurl拉取--runtimenode --target24.18.0的预编译二进制install-libcurl-node: node-pre-gyp install --directory node_modules/getinsomnia/node-libcurl --update-binary --runtimenode --target24.18.0第 2 步构建insomnia-inso生成distnpm run build -w insomnia-inso对应 packages/insomnia-inso/package.json 中的build: esr esbuild.ts。esbuild 配置见 esbuild.tsplatform: node、target: node22、输出 CJS 到./dist/index.js且把getinsomnia/node-libcurl声明为external不进 bundle运行时从node_modules动态加载原生二进制——这就是为什么第 1 步装错运行时会导致加载失败。第 3 步启动 CLI 测试依赖的 smoke-test 服务npm run serve -w insomnia-smoke-test该脚本在 packages/insomnia-smoke-test/package.json 中定义为serve: esr server/index.ts服务监听端口固定为 4010见 server/index.ts 第 45 行const port 4010;。CI 中用wait-on http://localhost:4010等待端口就绪本地则保持该终端常开。第 4 步在另一个终端跑 bundle 测试套件npm run test:bundle -w insomnia-insopackages/insomnia-inso/package.json 中该脚本为vitest cli.test.ts -t inso dev bundle即只执行 cli.test.ts 中名为inso dev bundle的describe块。第 5 步若 CI 失败点在打包二进制路径或 bundle 测试本地已全绿再跑 binary 测试npm run test:binary -w insomnia-inso脚本为vitest cli.test.ts -t inso packaged binary它执行同一套命令断言但把被测对象从bin/inso经由 esbuild 产出的开发入口替换为binaries/insonpm run package -w insomnia-inso由yao-pkg/pkg打包出的可执行文件见 package.json 的package: npx -y yao-pkg/pkg6.14.1 . --output binaries/inso --targets host。第 6 步收尾Teardown验证完成后停掉npm run serve -w insomnia-smoke-test进程重新安装 Electron 目标的 libcurl避免影响后续 Electron 开发npm run install-libcurl-electron根 package.json 中对应--runtimeelectron --target43.2.0。注意根目录的postinstall钩子默认执行的就是install-libcurl-electronpatch-package npm run verify-bundle-plugins -w insomnia npm run install-libcurl-electron所以任何一次npm ci之后本地环境都会回到 Electron 二进制状态需要重跑test:bundle时必须重新执行第 1 步。三、核心原理为什么 Node 与 Electron 二进制不兼容insomnia-inso的请求发送最终依赖getinsomnia/node-libcurl这个原生 Node 模块。Electron 与 Node 各自编译的 ABI即NODE_MODULE_VERSION不同node-pre-gyp的--target参数决定了预编译二进制绑定到哪一侧运行时install-libcurl-node--runtimenode --target24.18.0供inso在纯 Node 环境bundle 测试、inso用户中加载install-libcurl-electron--runtimeelectron --target43.2.0供桌面 App 开发使用。加载错版本时典型报错就是NODE_MODULE_VERSION不匹配、dlopen失败或原生模块加载异常。这也是 SKILL.md “Common failure patterns” 第一条的依据凡错误信息里出现getinsomnia/node-libcurl、NODE_MODULE_VERSION、dlopen或原生模块加载字样优先怀疑 libcurl 二进制与当前运行时不匹配用npm run install-libcurl-node重装即可。从源码结构看这条链路的其余环节同样依赖 Node 侧esbuild.ts 把platform设为node并将.renderer后缀的模块重定向到.node变体rendererToNodePlugin进一步说明 inso 是一个纯 Node 构建产物与 Electron 渲染进程隔离。四、常见失败模式速查SKILL.md 归纳了三类高频故障结合测试源码可以给出更精确的判别位置症状根因处理getinsomnia/node-libcurl/NODE_MODULE_VERSION/dlopen/ 原生模块加载错误libcurl 二进制是 Electron 目标版本或版本漂移npm run install-libcurl-node重装后重跑连接http://localhost:4010失败smoke-test 服务未启动。测试入口 cli.test.ts 的beforeAll会先fetch(http://localhost:4010)探活探活失败整个套件直接报错保持npm run serve -w insomnia-smoke-test常驻缺少dist输出或缺少binaries/insonpm run build -w insomnia-inso或npm run package -w insomnia-inso未执行/失败重新执行对应构建或打包步骤prepackage会先build:production并清理旧binaries/inso补充两个便于定位的细节bundle 与 binary 两条路径复用同一份命令断言。cli.test.ts 用shouldReturnSuccessCode/shouldReturnErrorCode两个命令列表覆盖lint spec、export spec、run test、run collection含鉴权、正则过滤、after-response 脚本、环境变量覆盖、超时、客户端证书等场景断言退出码为 0 或 1inso packaged binary块则把同一列表中的bin/inso批量替换为binaries/inso再跑一遍。因此 CI 日志里如果只有打包路径失败、bundle 路径全绿问题大概率出在pkg打包阶段如kong资源的pkg.scripts打包规则而不是 CLI 逻辑本身。部分用例还会校验 verbose 输出内容如console log appears in timeline断言HTTP/1.1 200 OK、foo bar baz这些请求打到http://127.0.0.1:4010/的 echo 端点进一步印证 smoke-test 服务是这些断言的硬依赖。五、成功判据SKILL.md 给出的验收标准是npm run test:bundle -w insomnia-inso正常退出exit 0Vitest 报告inso dev bundle用例全部通过若同时验证打包二进制路径npm run test:binary -w insomnia-inso也正常退出。两条判据分别对应 CI 中Run Inso bundle e2e tests与Run Inso binary e2e tests两个步骤本地全绿即可视为对该test-cli.yml失败的修复完成若仍需验证产物可参照 CI 的artifacts步骤在本地执行npm run artifacts -w insomnia-inso生成压缩包自查。附适用前提与限制流程基于当前仓库的 Node24.18.0.nvmrc为24.18.0、npm11环境见根 package.json 的engines字段install-libcurl-node的--target24.18.0与install-libcurl-electron的--target43.2.0均写死在根package.json脚本中若升级 Node 或 Electron 版本需同步更新这两个 target 才能拉取匹配的预编译二进制本文仅说明查看、安装与运行方式不涉及对仓库内容的修改。【免费下载链接】insomniaThe open-source, cross-platform API client for GraphQL, REST, WebSockets, SSE and gRPC. With Cloud, Local and Git storage.项目地址: https://gitcode.com/GitHub_Trending/in/insomnia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
