k6 v0.59.0 发布解读：镜像 v1.0.0-rc2 的版本策略、Cloud 扩展原生支持与 execution.test.fail 失败控制

k6 v0.59.0 发布解读镜像 v1.0.0-rc2 的版本策略、Cloud 扩展原生支持与 execution.test.fail 失败控制【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6k6 v0.59.0 是 grafana/k6 在迈向 v1.0.0 稳定版过程中的一个特殊版本它的内容与v1.0.0-rc2完全一致但以v0.*版本号重新发布目的是让各类自动化工具能够将其识别为最新稳定版本。本文以仓库内的 release notes/v0.59.0.md 与 release notes/v1.0.0-rc2.md 为骨架深入解读这套镜像版本策略的动机与适用场景并围绕该版本的核心新特性——Cloud 扩展的原生支持Binary Provisioning与execution.test.fail失败控制——结合仓库源码剖析其实现原理与实战用法帮助读者理解如何将测试升级到该版本、如何使用新增 API 控制测试结果。一、v0.59.0 是什么一份镜像版本的来龙去脉版本策略背景为什么需要镜像发布k6 的版本号体系经历过一个特殊阶段在官方稳定版v1.0.0发布之前项目一直以v0.*系列如v0.57.0、v0.58.0对外发布而这些版本实际上承担着稳定版的角色。当进入发布候选阶段后团队以v1.0.0-rc1、v1.0.0-rc2的形式发布候选版本问题随之而来Homebrew 的 k6 formula和pkg.go.dev这类自动化工具遵循 SemVer 惯例默认不会自动拉取v1.0.0-rc2这类不稳定pre-release版本这属于它们的合理预期行为但此前所有v0.*版本都被这些工具视为最新稳定版即便v0.*本身通常被语义化版本规范解读为不稳定系列。为了解决这一矛盾项目采用了一套过渡策略在必要的发布候选版本发布时同步以v0.*号发布一份镜像版本确保自动化工具能持续识别到最新可用版本。v0.58.0镜像v1.0.0-rc1见 release notes/v0.58.0.md而本篇文章讨论的v0.59.0则完整镜像了v1.0.0-rc2。官方明确承诺该实践将在正式稳定版v1.0.0发布后终止届时将回归标准的 SemVer 生命周期简化所有人的工作流。因此对于使用者而言v0.59.0与v1.0.0-rc2是同一份代码、同一组变更只是版本号不同如果只想跟随自动化工具眼中的最新版直接使用v0.59.0即可。镜像版本的实际影响理解这一策略对实际使用有两点直接帮助升级行为可预期brew upgrade k6、go install等工具在v1.0.0正式发布前仍能获取到最新能力包括本文下述的 Cloud 扩展支持与execution.test.fail变更清单以 rc2 为准v0.59.0相对v0.58.0的全部变更明细记录在v1.0.0-rc2的发布说明中阅读时两者应互为对照。二、核心新特性一Cloud 中原生支持 k6 扩展Binary Provisioning功能概述与适用场景过去要在脚本中使用 k6 扩展如xk6构建的自定义模块用户必须手动重新编译 k6 二进制流程繁琐且难以在 CI 中落地。v1.0.0-rc2即v0.59.0引入的Binary Provisioning二进制自动供应特性改变了这一局面系统会根据测试所需的扩展依赖自动请求并使用对应的自定义 k6 二进制二进制在本地缓存后续使用相同依赖的测试会复用同一份二进制运行更快对所有 k6 Cloud 用户免费版与付费版开放。启用方式与限制项目说明启用开关实验特性需通过环境变量显式开启K6_BINARY_PROVISIONINGtrue支持范围仅支持有限集合的扩展不支持的入口暂时不适用于本地k6 run命令未来可能加入本地开发可通过k6 cloud --local-execution在本地执行前提是已通过官方登录方式提供 Cloud token需要注意该特性在仓库中的定位是实验特性experimental官方文档对支持的扩展清单有明确限定使用前应确认自己的扩展是否在支持集合内。三、核心新特性二execution.test.fail —— 显式标记测试失败而不中断执行设计动机与 abort 的本质区别在execution.test.fail出现之前脚本控制测试结束的唯一手段是execution.test.abort()它会立即中断整个测试运行。而在某些场景下我们希望明确判定测试失败但同时让执行继续到自然结束——例如希望继续收集完整的指标数据、完成必要的清理teardown任务。这正是execution.test.fail的设计目标。两者行为对比如下函数行为底层机制execution.test.abort(reason?)立即中断测试引擎执行通过rt.Interrupt抛出InterruptError见 errext/interrupt_error.goexecution.test.fail(reason?)将测试标记为失败但继续执行到完成记录日志 将TestStatus置为 failed见 lib/test_state.go源码级实现剖析execution.test.fail的核心实现在 internal/js/modules/k6/execution/execution.go 的newTestInfo中fail: func() any { return func(msg sobek.Value) { reason : errext.MarkedAsFailedTest if !common.IsNullish(msg) { reason fmt.Sprintf(%s: %s, reason, msg.String()) } if mi.vu.State() nil { common.Throw(rt, fmt.Errorf(execution.test.fail() called outside of VU context)) } mi.vu.State().Logger.Errorf(reason) mi.vu.State().TestStatus.MarkFailed() } },关键点在于标记而非中断与abort分支调用rt.Interrupt(errext.InterruptError{...})不同fail分支不打断运行时而是调用TestStatus.MarkFailed()默认原因与自定义原因不传参数时默认原因字符串为errext.MarkedAsFailedTest常量值为test marked as failed定义于 errext/interrupt_error.go传参时拼接为test marked as failed: 自定义原因上下文校验在 VU 上下文之外调用会直接抛出execution.test.fail() called outside of VU context错误——例如在 init 阶段调用是不允许的日志记录失败原因会通过 VU 的 Logger 以 Error 级别输出。TestStatus的类型定义与状态机位于 lib/test_state.gotype TestStatus struct { failed bool failedOnce sync.Once } func (ts *TestStatus) MarkFailed() { ts.failedOnce.Do(func() { ts.failed true }) } func (ts *TestStatus) Failed() bool { return ts.failed }值得注意的设计细节是sync.Once的引入即使多个 VU 或 goroutine 同时调用fail测试也只会被标记为失败一次避免了并发写导致的竞态问题这也与 rc2 中修复执行状态竞态条件的整体方向一致。测试用例佐证仓库中的单元测试 internal/js/modules/k6/execution/execution_test.go 完整覆盖了该 API 的两种调用形态TestFailTest的 default reason 子用例执行exec.test.fail()后断言state.TestStatus.Failed()为 trueTestFailTest的 custom reason 子用例执行exec.test.fail(a custom reason)后除断言失败状态外还断言日志缓冲区中包含了自定义原因字符串a custom reason对照用例TestAbortTest执行exec.test.abort()/exec.test.abort(mayday)后断言抛出的是*sobek.InterruptedError且内部封装了*errext.InterruptErrorReason 分别为test aborted与test aborted: mayday。这两个对照测试非常清晰地印证了中断与标记失败两条路径的差异。实战示例以下脚本演示了如何在持续执行的同时标记测试失败import { exec } from k6/execution; import http from k6/http; export const options { scenarios: { smoke: { executor: constant-vus, vus: 5, duration: 30s, }, }, }; export default function () { const res http.get(https://test.k6.io/); // 业务上判定不可接受时标记测试失败但让本轮迭代继续执行 if (res.status ! 200) { exec.test.fail(unexpected status code: ${res.status}); } // 后续代码与指标收集、teardown 清理仍会正常完成 console.log(iteration completed, status${res.status}); } export function teardown() { // fail() 不会中断执行teardown 依然会被执行 console.log(cleaning up resources...); }运行该测试后k6 会照常完成全部迭代并输出完整摘要但测试的最终结果为失败对应退出码层面也会体现为失败。如果希望在失败时立即终止执行则应改用exec.test.abort()。四、用户体验改进与 Bug 修复除上述两大特性外该版本还包含若干值得关注的改进UX 改进阈值默认展示#4698即使某个阈值未配置在summaryTrendStats选项中其阈值数值也会在摘要中显示便于核对阈值生效情况移除 User-Agent 中的旧网站链接#4699精简请求标识避免暴露过时的官网地址。Bug 修复浏览器模块并发安全#4717防止pressedKeys被并发更新导致的数据竞争执行状态竞态#4665消除Ended与Interrupted两种执行状态之间的竞态条件secretsource 脱敏覆盖扩大#4677使secretsource对float32与float64类型的值同样进行脱敏。在 secretsource/hook.go 的类型分支中可以看到脱敏处理覆盖了int、uint、各宽度整型以及float32、float64等类型。维护与内部重构作为 v1.0.0 稳定化前的准备工作该版本还进行了多项内部调整多个包被迁移至internal目录为 v1.0.0 的公开 API 收敛做准备#4675、#4676、#4678移除冗余的NO_COLOR检测逻辑#4686修复 JS 原生对象被测试页面覆盖的问题避免测试页面意外改写Set、Map等原生对象#4709统一internal与cmd的Execute方法#4726修复 WebCrypto 错误未从测试中正确传播的问题#4701升级OpenTelemetry、grpc、golang/x、esbuild及x509roots/fallback等依赖#4691、#4674、#4673、#4663移除已弃用的 CDPGetLayoutMetrics.VisualViewport用法#4739。这些变更大多属于对 v1.0.0 稳定版的铺垫工作普通用户无需感知但升级后二进制体积、启动行为与错误输出可能略有变化。五、升级建议与总结如何获取 v0.59.0通过 Homebrewbrew upgrade k6、go install或官方打包渠道安装v0.59.0即可获得与v1.0.0-rc2完全一致的能力尝鲜 Cloud 扩展若在 k6 Cloud 中使用扩展设置K6_BINARY_PROVISIONINGtrue后即可体验自动二进制供应本地联调使用k6 cloud --local-execution改造失败处理逻辑如果现有脚本用exec.test.abort()中断测试后丢失了指标或清理逻辑可评估迁移到exec.test.fail()在保留完整数据收集与 teardown 的前提下显式标记失败版本策略预期v0.*镜像版本是 v1.0.0 发布前的临时过渡正式稳定版发布后将回归标准 SemVer届时升级路径会更简单。总而言之v0.59.0是一个内容等同 rc2、版本号服务自动化工具的特殊版本对自动化使用者而言它是当前可获取的最新稳定版本对功能而言它带来了 Cloud 扩展原生支持与更精细的测试失败控制能力为 k6 进入 v1.0.0 稳定时代完成了关键铺垫。【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考