TensorZero Helm Chart 发布指南从 CI 自动发布到 ArtifactHub 与 values 模式校验【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzeroTensorZero 在 examples/production-deployment-k8s-helm 目录中维护着一个可发布到 ArtifactHub 的 Helm Chart用于在 Kubernetes 上部署 TensorZero Gateway、TensorZero UI 与 ClickHouse 等组件。本文围绕该目录下的发布文档完整讲解 Chart 的版本管理、手动发布流程、Cloudflare R2 制品托管方式以及values.schema.json的自动生成与校验机制读者可按步骤完成一次从版本号提升到 ArtifactHub 上架的全流程操作。发布机制总览TensorZero 的 Helm Chart 发布分为两条路径CI 自动发布每当仓库创建新的 GitHub Release 时CI 流水线会自动提升 Chart 版本号并将其发布到 ArtifactHub 的tensorzero包页面。制品实际托管在 Cloudflare R2 存储桶tensorzero-helm-charts上通过https://helm.tensorzero.com对外提供 Helm 仓库索引。手动发布由维护者在本机执行helm相关命令完成打包、上传与索引更新的全过程适合在 CI 不可用或需要手工干预的场景下使用。Chart 本身位于 examples/production-deployment-k8s-helm/Chart.yaml其apiVersion: v2Helm 3 标准格式name: tensorzerotype: application。值得注意的是其中的版本字段apiVersion: v2 name: tensorzero description: A Helm chart for Kubernetes with deployment, secret, configmap, service, and ingress type: application version: 0.0.0 # updated by CI appVersion: 2026.5.2version: 0.0.0是占位符由 CI 在发布时替换为真实版本号appVersion则与仓库主版本保持一致。仓库中的 ci/check-version-consistency.sh 会校验crates/Cargo.toml的版本、ui/package.json的版本与 Chart 的appVersion三者一致确保发布出去的 Chart 与 Gateway、UI 的实际版本严格对应。前置条件要参与 Chart 的修改与发布需要准备Helm 3.2.0 及以上版本这是使用 API Version v2 的 Chart 和helm package、helm repo index等命令的最低要求。helm-values-schema-json插件用于从values.yaml自动生成values.schema.jsonhelm plugin install https://github.com/losisin/helm-values-schema-json.git该插件是本文Values Schema 生成环节的核心工具缺少它时本地无法自动再生成模式文件CI 中的模式同步校验也会因此失败。另外手动发布还隐式要求具备对 Cloudflare R2 存储桶tensorzero-helm-charts的上传权限通常通过rclone或aws兼容命令完成需使用你的 R2 凭据以及一个可用的 Helm 仓库客户端用于生成和合并index.yaml。手动发布 Helm Chart 到 ArtifactHub在 CI 不可用或需要手工发版时按以下步骤操作即可完成发布。其核心逻辑是打包 Chart → 上传压缩包 → 重建仓库索引 → 让 ArtifactHub 扫描到新版本。1. 提升 Chart.yaml 中的版本号编辑 examples/production-deployment-k8s-helm/Chart.yaml将version从占位符0.0.0或上一个发布版本提升为本次要发布的新版本例如1.2.3。版本号需要遵循语义化版本规范ArtifactHub 会根据版本号识别新版本并更新列表。2. 打包 Charthelm package .执行后会在当前目录生成tensorzero-x.y.z.tgz其中x.y.z即 Chart.yaml 中填写的版本号。打包会递归包含 templates 下的所有模板、values.yaml 与values.schema.json等文件。3. 上传压缩包到 Cloudflare R2将tensorzero-x.y.z.tgz上传到 R2 存储桶tensorzero-helm-charts。这一步可使用支持 S3 兼容接口的客户端如awsCLI 或rclone完成上传后制品即通过https://helm.tensorzero.com/tensorzero-x.y.z.tgz对外可访问。4. 重建仓库索引 index.yamlhelm repo index . --url https://helm.tensorzero.com --merge index.yaml这条命令会扫描当前目录下已有的.tgz制品为每个版本生成对应的entries条目。注意两点--url https://helm.tensorzero.com指定了制品的基础 URL生成的索引中下载地址才会指向正确的托管位置--merge index.yaml会将本地已有的index.yaml与新生成的索引合并避免覆盖历史版本条目——如果不加--merge旧的版本信息会丢失导致用户无法再安装旧版本。5. 上传 index.yaml将更新后的index.yaml上传到同一个 R2 存储桶tensorzero-helm-charts替换桶中的旧索引文件。6. 等待 ArtifactHub 扫描上传完成后ArtifactHub 通常会在几分钟内扫描该存储桶并更新包列表。届时在 ArtifactHub 的tensorzero包页面即可看到新版本及其元数据Chart 描述、图标、README 等。Values Schema 的生成与同步校验values.schema.json是 Helm Chart 的 values 校验模式文件当用户执行helm install/helm upgrade时Helm 会按 Helm Chart Schema 文件 的约定读取该文件对传入的values.yaml做 JSON Schema 校验在安装前就拦截非法配置。本地自动生成pre-commit 钩子该文件不是手工维护的而是由helm-values-schema-json插件从 values.yaml 自动生成当你修改values.yaml后pre-commit 钩子会自动运行插件重新生成values.schema.json提交代码时必须把更新后的values.schema.json一并提交保持模式与 values 定义同步。生成的模式是标准的 JSON SchemaDraft 2020-12以 values.schema.json 为例gateway.image.tag字段就带有从values.yaml注释继承而来的描述信息tag: { description: The tag of the gateway image. If empty, uses Chart.appVersion, type: string }这得益于values.yaml中内联的# schema description:注释语法例如serviceAccountName与tag字段上的注释都会被插件提取进生成的模式文件。也就是说在values.yaml中书写schema注释就是为 Helm 用户提供字段级文档与校验规则的推荐方式。CI 中的同步校验仓库的 CI 通过 ci/check-helm-schema-sync.sh 验证已提交的values.schema.json与values.yaml是否一致脚本先确认examples/production-deployment-k8s-helm/values.schema.json文件存在然后执行git diff --quiet HEAD -- $SCHEMA_JSON检查该文件是否有未提交的改动若存在差异说明本地重新生成的模式与提交版本不一致CI 会输出 diff 并报错退出若一致则输出 Schema is in sync 通过校验。这意味着如果你改了values.yaml却没有提交重新生成的values.schema.jsonCI 会直接失败。这是保证 Chart 校验能力不失效的自动化防线。版本一致性与发布保障除了模式同步发布链路还有一道版本一致性检查。仓库根目录的 ci/check-version-consistency.sh 会从三个来源提取版本号并断言它们相等CARGO_VERSION$(grep ^version crates/Cargo.toml | sed s/version \(.*\)/\1/) UI_VERSION$(grep version: ui/package.json | sed s/.*version: \(.*\).*/\1/) CHART_VERSION$(grep ^appVersion: examples/production-deployment-k8s-helm/Chart.yaml | sed s/appVersion: \(.*\)/\1/)三者任一不一致都会导致检查失败从而在发布前就发现Gateway 二进制版本、UI 版本与 Chart 声明的 appVersion 脱节的问题。这也解释了为什么 Chart 的appVersion必须手动同步到与仓库主版本一致——它是用户从 ArtifactHub 判断这个 Chart 对应哪个 TensorZero 版本的关键依据。发布后的验证与使用发布完成后用户可以像使用任何公共 Helm 仓库一样使用该 Chart。仓库中的 examples/production-deployment-k8s-helm/README.md 给出了安装示例将examples/production-deployment-k8s-helm目录替换为已发布的 Chart 即可kubectl create namespace tensorzero helm upgrade --install tensorzero . -f values.yaml -n tensorzero部署成功后即可调用 Gateway 的 OpenAI 兼容端点验证发布产物可用先通过kubectl port-forward service/tensorzero-gateway -n tensorzero 3000:3000打通本地端口curl -X POST http://localhost:3000/openai/v1/chat/completions \ -H Content-Type: application/json \ -d { model: tensorzero::model_name::openai::gpt-4o-mini, messages: [ { role: user, content: What is the capital of Japan? } ] }关键注意事项--merge index.yaml不可省略手动重建索引时不加--merge会丢失历史版本条目破坏已有用户的升级路径。values.schema.json必须与values.yaml同步提交这是本地 pre-commit 钩子与 CI 双重约束的硬性要求忘记提交会导致 CI 失败。版本号提升后务必同步appVersionappVersion对应实际的 TensorZero 版本由 ci/check-version-consistency.sh 强制约束三者Cargo 版本、UI 版本、Chart appVersion必须一致。ArtifactHub 扫描存在延迟上传制品与索引后列表更新通常在几分钟内完成无需额外操作可稍后刷新确认。小结TensorZero 的 Helm Chart 发布链路是一条CI 自动为主、手动兜底的完整流程版本号由 CI 提升并与仓库主版本保持严格一致制品托管在 Cloudflare R2仓库索引由helm repo index维护最终由 ArtifactHub 扫描上架同时values.schema.json通过helm-values-schema-json插件自动生成并由 pre-commit 钩子与 ci/check-helm-schema-sync.sh 双重保障其与values.yaml的同步。理解了这套机制你既可以独立完成一次手动发版也能在修改values.yaml时遵循模式再生成的约定确保 Chart 在安装阶段始终能提供可靠的配置校验。【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考