尧图网站建设 
开发工具CI/CD质量保障【免费下载链接】lighthouse-ciAutomate running Lighthouse for every commit, viewing the changes, and preventing regressions项目地址https://gitcode.com/gh_mirrors/li/lighthouse-ci点击查看免费下载导读本文以 Lighthouse CILHCI官方迁移指南为主体系统讲解在 CLI 与 Server 两个组件间如何规划版本升级、理解 Server-CLI 兼容性规则、识别破坏性变更Breaking Changes的触发模式并逐版本梳理0.3.0到0.7.0之间每一处影响面与对应的处理方式。读完本文你将能制定一套先升 CLI、再升 Server的可靠升级流程并在升级前后快速自查assert断言、staticDistDir收集、自定义 Server API 调用等高风险使用模式。全文内容与仓库源码、测试相互印证可在当前仓库中逐一回溯验证。版本升级总览LHCI 的迁移主要发生在两个层面CLI 端lhci/cli负责收集 Lighthouse 报告、运行断言、上传结果与Server 端lhci/server负责存储构建与运行数据、提供统计与展示。迁移指南建议用户始终关注这两者的版本关系而不是孤立地升级某一个组件。从仓库结构看CLI 与 Server 同属一个 monorepo根 package.json 通过workspaces: [packages/*]管理但它们以独立的 npm 包发布因此在升级时可能处于不同版本这也是迁移指南专门强调兼容性的原因。Patch 更新通常无需任何操作Patch补丁版本更新通常不需要用户做任何特定操作。这是升级成本最低的一类变更主要包含 bug 修复与细微调整。唯一的例外是如果新特性需要 SQL 迁移Server 会在启动时自动执行迁移。这一自动执行机制在源码中有明确实现。在 packages/server/src/api/storage/sql/sql.js 中Server 通过Umzug迁移工具管理数据库结构其initialize方法在每次启动时都会执行await umzug.up()sql.js自动把未应用的迁移文件按顺序应用到数据库。迁移文件位于 packages/server/src/api/storage/sql/migrations/ 目录仓库中已包含从20191008-initial.js到20240122-project-name.js的多个历史迁移例如20191009-project-token.js引入项目令牌2019111001-statistic-version.js引入统计版本字段2020030501-admin-token.js引入管理员令牌2020032401-base-branch.js引入基线分支配置20240122-project-name.js调整项目名称相关结构。因此只要保持 Server 版本正确见下文兼容性规则Patch 升级后启动 Server 即可自动完成结构演进无需手工执行 SQL。Server-CLI 版本兼容性承诺这是迁移指南中最核心的规则值得用最谨慎的态度对待LHCI 承诺CLI 版本n始终兼容 Server 版本n - 1。由此导出的平滑迁移顺序是先升级lhci/cli依赖让新版本的 CLI 上报数据到当前旧一版的 Server再升级 Server 至与 CLI 匹配的版本。该承诺的反方向不成立先升级 Server、后升级客户端CLI可能导致数据丢失。原因在于旧版 CLI 可能不认识新版 Server 写入的数据结构例如新的统计命名、新的字段上传或读取时可能出现字段缺失、校验失败甚至覆盖/丢弃数据。因此无论升级到哪个大版本都应当严格遵循CLI 先行、Server 随后的顺序。如何判断你是否受影响迁移指南对每个版本都给出了受影响的使用模式Affected Usage Patterns清单。这些清单是判断升级影响面的核心工具——如果你的使用方式不在清单内大概率不会遇到破坏性变更。清单中反复出现三类高风险模式这里结合仓库源码逐一说明其含义1.lighthouse:*断言预设使用者assert命令支持--preset参数可选值为lighthouse:all、lighthouse:recommended、lighthouse:no-pwa定义见 packages/cli/src/assert/assert.js。这些预设会随 Lighthouse 版本升级而变化——新增审计项、移除旧审计项、调整分数权重都会直接改变断言结果。预设的宽松度可能收紧新版 Lighthouse 引入新审计后lighthouse:recommended会随之新增断言旧版本通过的构建在新版本下可能失败预设的审计集合会变化例如在 packages/utils/src/presets/recommended.js 中可以看到当前 recommended 预设对bootup-time、speed-index、interactive等审计使用warn级别对offscreen-images、unminified-css等使用error级别并且将uses-http2、long-tasks直接设为off。不同 Lighthouse 版本下这套集合并不相同。另外注意 packages/cli/src/autorun/autorun.js 中autorun在未显式配置assert时默认追加--presetlighthouse:recommended所以默认使用 autorun 的用户同样属于预设使用者升级后断言结果可能变化。2.assert自定义断言使用者不使用预设、而是手写assertions的用户同样受影响部分审计被移除对应断言自然失效、部分审计分数计算方式变化阈值判定可能翻转。断言的实际执行逻辑见 packages/utils/src/assertions.js 与 packages/cli/src/assert/assert.jsassert命令会读取.lighthouseci/中的 LHR 文件逐条比对minScore、maxLength、maxNumericValue等属性任何error级别的失败都会以退出码 1 结束进程。3. 自定义 LHCI Server API 使用者0.3.0起如果你直接调用 Server 的 HTTP API而不是通过 CLI 上传需要注意请求头与统计命名的变化详见下一节各版本明细。逐版本迁移明细以下按迁移指南原文的版本顺序完整列出每一版升级的受影响模式与破坏性变更并结合仓库现状补充说明。0.6.0→0.7.0受影响的使用模式lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败。若你的使用不涉及以上模式大概率无破坏性变更。破坏性变更底层升级到Lighthouse 7.0.0多个类目分数计算方式改变recommended 预设中的审计集合发生变化。这意味着依赖新版 Lighthouse 的预设与自定义断言都需要重新校准阈值。升级前建议先在 CI 的暂存分支上运行一次lhci assert观察哪些审计从passing变为warning/failure再决定是否调整断言配置。0.5.0→0.6.0受影响的使用模式lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败。破坏性变更底层升级到Lighthouse 6.4.1多个类目分数计算方式改变recommended 预设新增审计项。0.4.0→0.5.0受影响的使用模式lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败。破坏性变更底层升级到Lighthouse 6.2.0多个类目分数计算方式改变recommended 预设新增审计项。0.3.0→0.4.0这是仓库迁移指南中影响面最广的一次升级受影响模式多达五类受影响的使用模式staticDistDir未显式提供url的使用新增了 URL 自动发现逻辑收集到的 URL 集合可能发生变化lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败自定义 LHCI Server API 使用新增请求头要求、统计命名变化API 调用可能失败自定义.lighthouseci/目录使用每次collect都会删除 HTML 报告数据可能丢失。破坏性变更构建统计使用_median后缀而不是_average例如性能类目统计由_average改为_median命名依赖旧命名的 API 调用方需要同步更新类目分数改为 Lighthouse 6.0 的权重统计口径整体切换collect在指定staticDistDir且未提供 URL 时会递归进入子目录收集从collect命令的选项定义packages/cli/src/collect/collect.js可以看到staticDistDir与autodiscoverUrlBlocklist的配合使用方式仓库测试目录 packages/cli/test/fixtures/collect-static-dir-autodiscover-limit/ 中准备了多页面的静态目录样本用于验证自动发现与数量限制行为默认断言变为minScore0.9即未显式配置断言时默认要求分数不低于 0.9。该默认值在 packages/utils/src/assertions.js 中有明确实现——minScore未定义且未手写断言时取0.9.lighthouseci/中的 HTML 报告在运行collect时也会被删除而不仅是 JSON从 packages/cli/src/collect/collect.js 导入的clearSavedReportsAndLHRs即可见这一清理行为自定义存放报告的目录需注意备份预设改为断言 Lighthouse 6.0 审计预设审计集合整体迁移API 请求头要求收紧POST /projects/:id/builds现在要求x-lhci-build-token请求头POST /projects/:id/builds/:id/runs与PUT /projects/:id/builds/:id/lifecycle同样要求x-lhci-build-token请求头。关于最后一点可在 packages/server/src/api/routes/projects.js 中看到当前版本的完整印证创建构建L125-L135、上报运行L192-L203、封存构建生命周期L214-L223三个路由均挂载了validateBuildTokenMiddleware。也就是说任何绕过 CLI、直接调用这三个接口的自动化脚本都必须携带项目令牌。版本策略为什么破坏性变更会频繁出现迁移指南引用了 docs/version-policy.md 作为补丁升级无需操作的依据。该文档进一步解释了 LHCI 的破坏性变更为何比核心 Lighthouse 更频繁LHCI 在0.x.x轨道上遵循 semver 语义补丁版本不得引入破坏性变更关键安全或稳定性修复除外破坏性变更的传播渠道是提交信息中的BREAKING CHANGE: 描述行并汇总进下一版本的 release notes升级前应重点关注 release notes 中的这一标记典型破坏性变更包括Node 最低版本提升约 1 次/年、Lighthouse 次版本升级引入新审计3-6 次/年、Lighthouse 主版本升级1-2 次/年、Server API 格式变化、断言预设收紧、flag/选项的移除或默认值变更相对温和的变更新增 flag、更宽松的预设、API 新增字段则通常不会破坏现有使用。理解这一节奏有助于把升级工作纳入常规维护计划而不是等到破坏性变更积累后再一次性处理。迁移实操检查清单综合迁移指南与仓库实现升级一个 LHCI 部署时可按下述顺序操作阅读目标版本的 release notes确认是否存在BREAKING CHANGE标记并对照本文受影响使用模式清单逐项自查升级lhci/cli依赖至目标版本保持 Server 暂不升级利用CLIn兼容 Servern - 1的承诺在暂存分支运行一轮完整流程collect→assert→upload重点观察预设/自定义断言的通过情况审计集合与分数口径变化staticDistDir自动发现到的 URL 集合是否符合预期.lighthouseci/目录中 JSON 与 HTML 报告的保留情况若使用自定义 API 脚本确认请求头与统计命名已同步更新升级 Server 至匹配版本启动时确认日志中出现迁移执行信息对应 sql.js 的running migrations/migrations performed验证历史数据完整性与新构建展示进入 Server 前端确认类目分数、统计曲线与基线对比正常。总结LHCI 的迁移体系由三条支柱构成CLI 先行、Server 随后的升级顺序、Patch 升级零操作的承诺配合 Server 启动时自动执行的 SQL 迁移、以及逐版本明确化的受影响模式清单。对普通用户而言只要避开assert预设/自定义断言、staticDistDir自动发现、自定义 Server API 与.lighthouseci/手工目录这几类高风险用法绝大多数升级都可以无感完成而使用了这些特性的团队则应当在每次升级前对照清单做一次完整回归即可把破坏性变更的影响降到最低。赞分享开发工具CI/CD质量保障【免费下载链接】lighthouse-ciAutomate running Lighthouse for every commit, viewing the changes, and preventing regressions项目地址https://gitcode.com/gh_mirrors/li/lighthouse-ci点击查看免费下载相关推荐Apache APISIX升级指南平滑升级与版本迁移Apache APISIX升级指南平滑升级与版本迁移 概述 Apache APISIX作为云原生API网关版本迭代频繁且功能强大。然而版本升级过程中往往会后端微服务云原生SafeLine升级指南版本平滑升级与数据迁移SafeLine升级指南版本平滑升级与数据迁移 引言为什么升级如此重要 在网络安全领域Web应用防火墙WAF的版本升级不仅是功能增强的体现更是安全WAF网络安全应用安全tts-server-android升级指南平滑迁移与版本兼容性最佳实践tts server android升级指南平滑迁移与版本兼容性最佳实践 tts server android是一款功能强大的Android系统TTS应用支语音后端音频上一篇企业级微信机器人构建高性能Java自动化解决方案的5大架构优势下一篇pydantic-sqlalchemy与SQLModel对比如何选择最适合你的ORM工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Lighthouse CI 迁移与版本升级指南：CLI 与 Server 的平滑升级实践
开发工具CI/CD质量保障【免费下载链接】lighthouse-ciAutomate running Lighthouse for every commit, viewing the changes, and preventing regressions项目地址https://gitcode.com/gh_mirrors/li/lighthouse-ci点击查看免费下载导读本文以 Lighthouse CILHCI官方迁移指南为主体系统讲解在 CLI 与 Server 两个组件间如何规划版本升级、理解 Server-CLI 兼容性规则、识别破坏性变更Breaking Changes的触发模式并逐版本梳理0.3.0到0.7.0之间每一处影响面与对应的处理方式。读完本文你将能制定一套先升 CLI、再升 Server的可靠升级流程并在升级前后快速自查assert断言、staticDistDir收集、自定义 Server API 调用等高风险使用模式。全文内容与仓库源码、测试相互印证可在当前仓库中逐一回溯验证。版本升级总览LHCI 的迁移主要发生在两个层面CLI 端lhci/cli负责收集 Lighthouse 报告、运行断言、上传结果与Server 端lhci/server负责存储构建与运行数据、提供统计与展示。迁移指南建议用户始终关注这两者的版本关系而不是孤立地升级某一个组件。从仓库结构看CLI 与 Server 同属一个 monorepo根 package.json 通过workspaces: [packages/*]管理但它们以独立的 npm 包发布因此在升级时可能处于不同版本这也是迁移指南专门强调兼容性的原因。Patch 更新通常无需任何操作Patch补丁版本更新通常不需要用户做任何特定操作。这是升级成本最低的一类变更主要包含 bug 修复与细微调整。唯一的例外是如果新特性需要 SQL 迁移Server 会在启动时自动执行迁移。这一自动执行机制在源码中有明确实现。在 packages/server/src/api/storage/sql/sql.js 中Server 通过Umzug迁移工具管理数据库结构其initialize方法在每次启动时都会执行await umzug.up()sql.js自动把未应用的迁移文件按顺序应用到数据库。迁移文件位于 packages/server/src/api/storage/sql/migrations/ 目录仓库中已包含从20191008-initial.js到20240122-project-name.js的多个历史迁移例如20191009-project-token.js引入项目令牌2019111001-statistic-version.js引入统计版本字段2020030501-admin-token.js引入管理员令牌2020032401-base-branch.js引入基线分支配置20240122-project-name.js调整项目名称相关结构。因此只要保持 Server 版本正确见下文兼容性规则Patch 升级后启动 Server 即可自动完成结构演进无需手工执行 SQL。Server-CLI 版本兼容性承诺这是迁移指南中最核心的规则值得用最谨慎的态度对待LHCI 承诺CLI 版本n始终兼容 Server 版本n - 1。由此导出的平滑迁移顺序是先升级lhci/cli依赖让新版本的 CLI 上报数据到当前旧一版的 Server再升级 Server 至与 CLI 匹配的版本。该承诺的反方向不成立先升级 Server、后升级客户端CLI可能导致数据丢失。原因在于旧版 CLI 可能不认识新版 Server 写入的数据结构例如新的统计命名、新的字段上传或读取时可能出现字段缺失、校验失败甚至覆盖/丢弃数据。因此无论升级到哪个大版本都应当严格遵循CLI 先行、Server 随后的顺序。如何判断你是否受影响迁移指南对每个版本都给出了受影响的使用模式Affected Usage Patterns清单。这些清单是判断升级影响面的核心工具——如果你的使用方式不在清单内大概率不会遇到破坏性变更。清单中反复出现三类高风险模式这里结合仓库源码逐一说明其含义1.lighthouse:*断言预设使用者assert命令支持--preset参数可选值为lighthouse:all、lighthouse:recommended、lighthouse:no-pwa定义见 packages/cli/src/assert/assert.js。这些预设会随 Lighthouse 版本升级而变化——新增审计项、移除旧审计项、调整分数权重都会直接改变断言结果。预设的宽松度可能收紧新版 Lighthouse 引入新审计后lighthouse:recommended会随之新增断言旧版本通过的构建在新版本下可能失败预设的审计集合会变化例如在 packages/utils/src/presets/recommended.js 中可以看到当前 recommended 预设对bootup-time、speed-index、interactive等审计使用warn级别对offscreen-images、unminified-css等使用error级别并且将uses-http2、long-tasks直接设为off。不同 Lighthouse 版本下这套集合并不相同。另外注意 packages/cli/src/autorun/autorun.js 中autorun在未显式配置assert时默认追加--presetlighthouse:recommended所以默认使用 autorun 的用户同样属于预设使用者升级后断言结果可能变化。2.assert自定义断言使用者不使用预设、而是手写assertions的用户同样受影响部分审计被移除对应断言自然失效、部分审计分数计算方式变化阈值判定可能翻转。断言的实际执行逻辑见 packages/utils/src/assertions.js 与 packages/cli/src/assert/assert.jsassert命令会读取.lighthouseci/中的 LHR 文件逐条比对minScore、maxLength、maxNumericValue等属性任何error级别的失败都会以退出码 1 结束进程。3. 自定义 LHCI Server API 使用者0.3.0起如果你直接调用 Server 的 HTTP API而不是通过 CLI 上传需要注意请求头与统计命名的变化详见下一节各版本明细。逐版本迁移明细以下按迁移指南原文的版本顺序完整列出每一版升级的受影响模式与破坏性变更并结合仓库现状补充说明。0.6.0→0.7.0受影响的使用模式lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败。若你的使用不涉及以上模式大概率无破坏性变更。破坏性变更底层升级到Lighthouse 7.0.0多个类目分数计算方式改变recommended 预设中的审计集合发生变化。这意味着依赖新版 Lighthouse 的预设与自定义断言都需要重新校准阈值。升级前建议先在 CI 的暂存分支上运行一次lhci assert观察哪些审计从passing变为warning/failure再决定是否调整断言配置。0.5.0→0.6.0受影响的使用模式lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败。破坏性变更底层升级到Lighthouse 6.4.1多个类目分数计算方式改变recommended 预设新增审计项。0.4.0→0.5.0受影响的使用模式lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败。破坏性变更底层升级到Lighthouse 6.2.0多个类目分数计算方式改变recommended 预设新增审计项。0.3.0→0.4.0这是仓库迁移指南中影响面最广的一次升级受影响模式多达五类受影响的使用模式staticDistDir未显式提供url的使用新增了 URL 自动发现逻辑收集到的 URL 集合可能发生变化lighthouse:*断言预设使用新增审计项被断言断言可能失败assert使用部分审计被移除、分数发生变化断言可能失败自定义 LHCI Server API 使用新增请求头要求、统计命名变化API 调用可能失败自定义.lighthouseci/目录使用每次collect都会删除 HTML 报告数据可能丢失。破坏性变更构建统计使用_median后缀而不是_average例如性能类目统计由_average改为_median命名依赖旧命名的 API 调用方需要同步更新类目分数改为 Lighthouse 6.0 的权重统计口径整体切换collect在指定staticDistDir且未提供 URL 时会递归进入子目录收集从collect命令的选项定义packages/cli/src/collect/collect.js可以看到staticDistDir与autodiscoverUrlBlocklist的配合使用方式仓库测试目录 packages/cli/test/fixtures/collect-static-dir-autodiscover-limit/ 中准备了多页面的静态目录样本用于验证自动发现与数量限制行为默认断言变为minScore0.9即未显式配置断言时默认要求分数不低于 0.9。该默认值在 packages/utils/src/assertions.js 中有明确实现——minScore未定义且未手写断言时取0.9.lighthouseci/中的 HTML 报告在运行collect时也会被删除而不仅是 JSON从 packages/cli/src/collect/collect.js 导入的clearSavedReportsAndLHRs即可见这一清理行为自定义存放报告的目录需注意备份预设改为断言 Lighthouse 6.0 审计预设审计集合整体迁移API 请求头要求收紧POST /projects/:id/builds现在要求x-lhci-build-token请求头POST /projects/:id/builds/:id/runs与PUT /projects/:id/builds/:id/lifecycle同样要求x-lhci-build-token请求头。关于最后一点可在 packages/server/src/api/routes/projects.js 中看到当前版本的完整印证创建构建L125-L135、上报运行L192-L203、封存构建生命周期L214-L223三个路由均挂载了validateBuildTokenMiddleware。也就是说任何绕过 CLI、直接调用这三个接口的自动化脚本都必须携带项目令牌。版本策略为什么破坏性变更会频繁出现迁移指南引用了 docs/version-policy.md 作为补丁升级无需操作的依据。该文档进一步解释了 LHCI 的破坏性变更为何比核心 Lighthouse 更频繁LHCI 在0.x.x轨道上遵循 semver 语义补丁版本不得引入破坏性变更关键安全或稳定性修复除外破坏性变更的传播渠道是提交信息中的BREAKING CHANGE: 描述行并汇总进下一版本的 release notes升级前应重点关注 release notes 中的这一标记典型破坏性变更包括Node 最低版本提升约 1 次/年、Lighthouse 次版本升级引入新审计3-6 次/年、Lighthouse 主版本升级1-2 次/年、Server API 格式变化、断言预设收紧、flag/选项的移除或默认值变更相对温和的变更新增 flag、更宽松的预设、API 新增字段则通常不会破坏现有使用。理解这一节奏有助于把升级工作纳入常规维护计划而不是等到破坏性变更积累后再一次性处理。迁移实操检查清单综合迁移指南与仓库实现升级一个 LHCI 部署时可按下述顺序操作阅读目标版本的 release notes确认是否存在BREAKING CHANGE标记并对照本文受影响使用模式清单逐项自查升级lhci/cli依赖至目标版本保持 Server 暂不升级利用CLIn兼容 Servern - 1的承诺在暂存分支运行一轮完整流程collect→assert→upload重点观察预设/自定义断言的通过情况审计集合与分数口径变化staticDistDir自动发现到的 URL 集合是否符合预期.lighthouseci/目录中 JSON 与 HTML 报告的保留情况若使用自定义 API 脚本确认请求头与统计命名已同步更新升级 Server 至匹配版本启动时确认日志中出现迁移执行信息对应 sql.js 的running migrations/migrations performed验证历史数据完整性与新构建展示进入 Server 前端确认类目分数、统计曲线与基线对比正常。总结LHCI 的迁移体系由三条支柱构成CLI 先行、Server 随后的升级顺序、Patch 升级零操作的承诺配合 Server 启动时自动执行的 SQL 迁移、以及逐版本明确化的受影响模式清单。对普通用户而言只要避开assert预设/自定义断言、staticDistDir自动发现、自定义 Server API 与.lighthouseci/手工目录这几类高风险用法绝大多数升级都可以无感完成而使用了这些特性的团队则应当在每次升级前对照清单做一次完整回归即可把破坏性变更的影响降到最低。赞分享开发工具CI/CD质量保障【免费下载链接】lighthouse-ciAutomate running Lighthouse for every commit, viewing the changes, and preventing regressions项目地址https://gitcode.com/gh_mirrors/li/lighthouse-ci点击查看免费下载相关推荐Apache APISIX升级指南平滑升级与版本迁移Apache APISIX升级指南平滑升级与版本迁移 概述 Apache APISIX作为云原生API网关版本迭代频繁且功能强大。然而版本升级过程中往往会后端微服务云原生SafeLine升级指南版本平滑升级与数据迁移SafeLine升级指南版本平滑升级与数据迁移 引言为什么升级如此重要 在网络安全领域Web应用防火墙WAF的版本升级不仅是功能增强的体现更是安全WAF网络安全应用安全tts-server-android升级指南平滑迁移与版本兼容性最佳实践tts server android升级指南平滑迁移与版本兼容性最佳实践 tts server android是一款功能强大的Android系统TTS应用支语音后端音频上一篇企业级微信机器人构建高性能Java自动化解决方案的5大架构优势下一篇pydantic-sqlalchemy与SQLModel对比如何选择最适合你的ORM工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考