云原生后端前端【免费下载链接】kubeappsA web-based UI for deploying and managing applications in Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/ku/kubeapps点击查看免费下载本文是 Kubeapps 开源项目的版本发布Release开发者指南。Kubeapps 是基于 Web 的 Kubernetes 应用部署与管理 UI仓库核心源码见 README.md其发布流程涉及开发镜像、CI 配置、Protobuf 生成代码、多语言依赖Go / Node / Rust、Helm Chart 与 Bitnami 官方仓库同步等多个环节。读完本文你将掌握 Kubeapps 维护者从更新依赖到发布并推广新版本的完整闭环操作包括每一步的命令、参数清单、必须遵守的约束以及常见协作事项。0. 第一步确保所有第三方依赖保持最新发布前的首要工作是减少过期的第三方依赖以便获得包含 bug 修复与安全补丁的最新版本。这一阶段分为四个子步骤更新开发镜像、更新 CI、更新 Chart、更新代码依赖。其核心原则是Kubeapps 的官方容器镜像由 Bitnami 构建因此仓库内自行维护的开发镜像必须与 Bitnami 使用的版本保持一致。0.1 开发镜像Development imagesKubeapps 用于构建 开发容器镜像 的 Dockerfile 分布在仓库多个目录中按语言分为三类Dashboard前端dashboard/Dockerfile 使用bitnami/node构建生产环境静态文件再使用bitnami/nginx作为简单 Web 服务器提供 HTML 与 JS 文件。从当前仓库实际内容可以看到构建阶段为bitnami/node:20.18.0运行阶段为bitnami/nginx:1.27.2。Golang 服务cmd/apprepository-controller/Dockerfile、cmd/asset-syncer/Dockerfile、cmd/kubeapps-apis/Dockerfile 均使用bitnami/golang构建二进制运行阶段则使用scratchkubeapps-apis 因需要动态加载插件.so文件而例外地使用bitnami/minideb。当前仓库中bitnami/golang:1.23.2。Rust 服务cmd/pinniped-proxy/Dockerfile、cmd/oci-catalog/Dockerfile 使用rust官方镜像构建二进制运行阶段使用bitnami/minideb当前为rust:1.81.0、bitnami/minideb:bookworm。此外部分镜像在构建阶段还会使用若干构建期 linter 或工具例如buflinter、gosec/golangci-lint检查器、grpc-health-probe等。以 cmd/kubeapps-apis/Dockerfile 为例其中声明了BUF_VERSION1.45.0、GOLANGCILINT_VERSION1.61.0、GRPC_HEALTH_PROBE_VERSION0.4.34等构建参数。更新基础镜像时这些工具版本应当同步升级到最新的 minor/patch 版本。发布流程要求这些镜像标签必须更新到最新的 minor/patch 版本若涉及 major 版本变更应当单独开 PR 跟踪。同时注意由于官方容器镜像由 Bitnami 创建应当确保我们使用的 major 版本与 Bitnami 一致。0.2 CI 配置与镜像版本为了让 CI 作业与容器镜像保持同步还需要更新 CI 中使用的镜像版本。相关背景可参考 CI 配置说明 与 e2e 测试文档。0.2.1 CI 配置中的版本变量在 .github/workflows/kubeapps-general.yaml 文件顶部的env块中集中声明了本次发布涉及的版本变量这些变量必须与构建容器镜像所用的版本一致。从当前仓库实际内容看这些变量及其约束如下变量当前值仓库现状更新约束GOLANG_VERSION1.23.2必须与 Golang 服务如 kubeapps-apis的 Dockerfile 一致NODE_VERSION20.18.0必须与 dashboard/Dockerfile 使用的major版本一致RUST_VERSION1.81.0必须与 pinniped-proxy / oci-catalog 的 Dockerfile 一致DOCKER_REGISTRY_VERSION2.8.3可更新到 Docker 提供的最新 tagHELM_VERSION_MINv3.8.0必须匹配 Bitnami Application Catalog 的前置要求HELM_VERSION_STABLEv3.16.2更新为 Helm 最新稳定版OLM_VERSIONv0.28.0更新为 OLM 最新稳定版CHARTMUSEUM_VERSION3.10.3更新为 chartmuseum 最新稳定版KAPP_CONTROLLER_VERSIONv0.50.6更新为 Kapp Controller 最新稳定版MKCERT_VERSIONv1.4.4更新为 mkcert 最新稳定版KUBECTL_VERSIONv1.30.5应与GKE_REGULAR_VERSION_XX的 Kubernetes minor 版本或 minor1匹配GITHUB_VERSION2.59.0更新为 GitHub CLI 最新稳定版SEMVER_VERSION3.4.0更新为 semver-tool 最新稳定版KIND_VERSIONv0.23.0更新为 kind 最新稳定版K8S_KIND_VERSIONv1.30.0sha256:...必须匹配GKE_REGULAR_VERSION_XX使用的 Kubernetes minor 版本并选用对应 Kind release 提供的镜像 tagPOSTGRESQL_VERSION17.0.0-debian-12-r3必须匹配 Bitnami PostgreSQL chart 使用的版本FLUX_VERSIONv2.2.3更新为 Flux 最新稳定版HUGO_VERSION见 0.5 节更新为 Hugo 最新稳定版同时GKE_STABLE_VERSION与GKE_REGULAR_VERSION当前均为1.30在 GKE 的 Stable / Regular Kubernetes 版本变化时也需要更新若设置了ALLOW_GKE_VERSION_FALLBACK当在 GKE 中找不到匹配版本时会回退到当前默认版本。更新GOLANG_VERSION时.github/workflows/codeql-analysis.yml 中 CodeQL GitHub Action 使用的 Go 版本可能也需要一并更新。发布流程要求上述变量中必须更新的部分务必修改到位其他变量变更应当在单独的 PR 中跟踪。0.2.2 CI 集成镜像与依赖运行 e2e 测试使用独立的集成镜像一个带依赖的 Node 镜像升级它包含两方面集成依赖integration/package.json 中的依赖可以通过以下命令升级cd integration yarn upgrade集成镜像integration/Dockerfile 使用mcr.microsoft.com/playwright镜像运行 e2e 测试当前仓库为mcr.microsoft.com/playwright:v1.48.1-jammy并执行npx playwright install安装浏览器。发布流程要求该 Node 镜像 tag可以更新到最新 minor/patch 版本major 版本变更应当单独 PR 跟踪其依赖同理。0.3 Protobuf 依赖与自动生成代码自引入新的 Kubeapps APIs 服务以来前端与后端代码都基于自动代码生成。生成规则会随工具演进因此需要定期更新升级buf相关依赖# 需要安装最新版 buf 二进制安装方式见 buf 官方安装文档 make buf-mod-update重新生成自动代码# 需要安装最新版 buf 二进制 make buf-generate从根目录 Makefile 可以看到这两个目标的实际定义buf-mod-update会依次执行buf dep update cmd/kubeapps-apis与buf dep update cmd/oci-catalogbuf-generate会依次执行cd cmd/kubeapps-apis buf generate、cd cmd/oci-catalog buf generate并对 dashboard 运行yarn prettier。作为该流程的一部分自动生成的 API 文档 cmd/kubeapps-apis/docs/kubeapps-apis.swagger.json 可能发生变化。如果变化了必须更新 dashboard 中捆绑的 dashboard/public/openapi.yaml。操作方式为先将自动生成的文件转换为 OpenAPI 3例如使用 Swagger 2.0 转 OpenAPI 3 的各类工具然后仅复制生成文件中的paths与components段到 dashboard 的openapi.yaml。最后注意openapi.yaml中的所有路径必须以/apis/前缀开头交互式 API 文档才能正常工作。发布流程要求buf.lock依赖必须更新到最新版本major 版本变更应当单独 PR 跟踪。0.4 升级代码依赖Kubeapps 的代码依赖分为三类dashboard 依赖、golang 依赖、rust 依赖。它们必须升级到最新 minor/patch 版本以获得最新的 bug 与安全修复。Dashboard 依赖升级 dashboard/package.json 中的依赖cd dashboard yarn upgrade注意如果有某些依赖当前无法更新yarn upgrade-interactive允许只选择其中部分条目升级。Golang 依赖先检查过期的依赖参考 Go Modules 升级/降级指南go mod tidy go list -u -f {{if (and (not (or .Main .Indirect)) .Update)}}{{.Path}}: {{.Version}} - {{.Update.Version}}{{end}} -m all 2 /dev/null然后尝试将当前模块的所有直接与间接依赖更新到最新版本go get -u ./...如果上述命令失败例如因传递依赖问题可以手动升级这些版本go-mod-upgrade。Rust 依赖分别升级两个 Rust 服务的依赖见 cmd/pinniped-proxy/Cargo.tomlcd cmd/pinniped-proxy/ cargo update以及cd cmd/oci-catalog/ cargo update安全检查与 chart 同步 PR最后查看仓库的 Pull Requests确保没有 Snyk 或kubeapps-bot打开的安全修复 PR 或上游 chart 变更 PR。如有需与其他 Kubeapps 维护者讨论并作出决定尽量避免带着高/中危安全问题发布。发布流程要求dashboard 依赖必须更新golang 依赖应当更新rust 依赖应当更新安全检查必须执行。发送升级 PR现在创建包含以上全部变更的 Pull Request仅当没有 bump 任何 major 版本时等待另一位 Kubeapps 维护者评审通过后合并。0.5 更新网站引擎Kubeapps 官网使用 Hugo 构建Hugo 是基于 Go 编写的静态站点生成器从 Markdown 文件与 HTML 模板生成网站托管在 Netlify 上——当新代码推送到 Git 仓库时 Netlify 会自动构建并部署网站。更新网站引擎需要将 site/netlify.toml 中的HUGO_VERSION变量更新到最新的 Hugo release。从当前仓库内容可见各 contextproduction、deploy-preview、branch-deploy 等均使用HUGO_VERSION 0.124.1构建命令为hugo --gc --minify --enableGitInfo。1. 选择待打 tag 的提交并执行测试依赖已更新、chart 变更已合并后下一步是选择合适的提交作为发布基础。通常这是 main 分支的最新提交。随后应执行一些手动与自动测试以确保发布版本的稳定性和可靠性。1.1 触发Full Integration Pipeline工作流前身是 CircleCI 中的prerelease流程Full Integration Pipeline是 GitHub Actions 中的手动工作流运行完整流水线包括在外部 k8s 集群目前仅 GKE通常由云厂商管理上执行的端到端测试。从仓库实际配置.github/workflows/kubeapps-full-integration.yaml可以看到它通过workflow_dispatch手动触发同时也有定时触发cron: 0 4 * * 1,3,6即每周一、三、六 04:00其核心是复用kubeapps-general.yaml并开启run_gke_tests: true。手动触发步骤如下进入 Kubeapps GitHub 仓库的 Actions 页面。在左侧工作流列表中点击Full Integration Pipeline。点击工作流运行列表右上角的Run Workflow下拉按钮。在分支列表中选择main默认项。点击Run workflow按钮。之后即可交互并观察刚创建的工作流运行。1.2 执行手动测试即使仓库拥有完善的测试套件仍必须在所选提交上对应用进行人工审查。步骤如下检出所选提交。使用开发 chart 安装 Kubeappshelm install kubeapps ./chart/kubeapps/ -n kubeapps注意如果你使用的不是 main 分支的最新提交可能需要本地构建容器镜像让集群使用正确的镜像。确保核心功能正常添加一个仓库Add a repository从目录中安装一个应用Install an application from the catalog升级该应用Upgrade this application删除该应用Delete this application在额外的集群中部署一个应用Deploy an application in an additional cluster2. 创建 git tag接下来为上述提交创建 tag 并推送到远端仓库。请注意tag 名称将直接用作 release 名称。检测到新 tag 后Bitnami 会基于该 tag 对应的提交自动构建一组容器镜像随后发布到 Bitnami 的 Docker Hub 镜像仓库。该工作流在 Kubeapps 发布流程管控之外运行。另外Bitnami Catalog 会在单个镜像发布时发布 chart 的一个版本因此如果 Kubeapps 各组件更新相互依赖需要小心处理——必要时可请求暂停 Kubeapps chart 发布直到所有镜像发布完毕。执行以下命令export VERSION_NAMEv1.0.0-beta.1 # 按需修改 git tag ${VERSION_NAME} -m ${VERSION_NAME} git push origin ${VERSION_NAME} # 将 origin 替换为你的远端名称也可以使用 semver tool 从最新已推送 tag 正确递增版本号来获取VERSION_NAMEexport VERSION_NAMEv$(semver bump major|minor|patch $(git fetch --tags git describe --tags $(git rev-list --tags --max-count1)))新 tag 推送到仓库后除常规的测试与构建步骤外还会触发Release Pipeline见 .github/workflows/kubeapps-release.yml。从该文件可以看到Release Pipeline 通过push到形如v[0-9].[0-9].[0-9]的 tag 触发并复用kubeapps-general.yaml工作流开启run_gke_tests: true、trigger_release: true。关于 Release Pipeline 的更多说明可参考 CI 文档。触发后的工作流示例如下3. 完善 GitHub release notes发布 job 完成后你会得到一个预填充的 GitHub release 草稿。你仍必须添加一个包含发布亮点release highlights的高层描述。请将仅做依赖升级bumping dependencies的提交单独拆开说明以免影响用户识别重要提交。随后保存草稿暂不发布并请另一位 Kubeapps 维护者评审这些发布说明。4. 人工审查 bitnami/charts 仓库中创建的 PRKubeapps 仓库托管的 chart 仅用于开发目的因此需要与 bitnami/charts 仓库 中的官方 chart 保持同步。为此CI 系统会在每次触发新 release 时通过sync_chart_to_bitnamijob对应工作流文件为 .github/workflows/kubeapps-sync-chart-to-bitnami.yaml详见 CI 文档自动向他们的仓库发送一个包含当前开发变更的 PR。PR 创建后请查看它例如移除不应发布的开发变更并等待 Bitnami 团队评审和接受。此处可能出现一些问题请检查应用版本是否被一次性正确更新并确保 PR 分支包含最新变更。注意 bitnami-bot 通常会向 main 分支执行一些自动提交可能与我们的 PR 变更冲突。特别是它会发布一个带更新镜像的新 chart 版本。5. 检查 Dockerfile 并通知相关团队随着 Kubeapps 代码持续演进我们的开发容器镜像中常会引入一些变更。但这些变更不会自动发布到官方 Bitnami 仓库除非我们手动通知相关团队将这些变更纳入他们的构建系统。发布流程要求每个 Kubeapps 组件的 Dockerfile必须与上一个 release 中的 Dockerfile 逐一对比。如果两者在功能上存在差异必须通知 Bitnami Content 团队。6. 确认发布版本已在 Bitnami 仓库中可用确认新版本现已公开可用搜索时应能看到正确的应用版本与 chart 版本helm repo update helm search repo kubeapps7. 发布 GitHub release一旦新版 Kubeapps 官方 chart 已发布、且 release notes 已评审通过就可以在 GitHub releases 页面点击publish按钮发布 release 了。注意chart 版本最终会作为 Bitnami 常规发布周期的一部分发布因此请预期这一步需要一定时间。8. 推广新版本在 Kubernetes Slack 的 #kubeapps 频道 中向社区告知新版本。如果包含重大特性还可以考虑在社交媒体上推广。附发布流程要点速查必须执行基础镜像 tag 更新到最新 minor/patch、CI 版本变量与 Dockerfile 保持一致、dashboard 依赖更新、安全检查、选择提交后手动测试、创建并推送 tag、完善并评审 release notes、人工审查 bitnami/charts PR、对比各组件 Dockerfile 并通知 Bitnami Content 团队、确认 Bitnami 仓库版本可用、最终发布并推广。应当单独开 PR 跟踪任何 major 版本升级、CI 中非发布必需的其他变量变更。版本命名tag 名即 release 名遵循vX.Y.Z形式Release Pipeline 通过匹配该 tag 模式触发也可按需使用v1.0.0-beta.1这类预发布版本。自动化触发push 匹配v[0-9].[0-9].[0-9]的 tag 即触发 Release Pipeline进而复用 .github/workflows/kubeapps-general.yaml 完成测试、构建与 chart 同步。赞分享云原生后端前端【免费下载链接】kubeappsA web-based UI for deploying and managing applications in Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/ku/kubeapps点击查看免费下载相关推荐Ginkgo 版本发布流程指南从 CHANGELOG 维护到 GitHub Release 的完整实操手册Ginkgo 版本发布流程指南从 CHANGELOG 维护到 GitHub Release 的完整实操手册 导读本文围绕 CRI O 仓库所依赖的 Gink云原生容器运行时RxAndroid 发布流程全指南从版本号管理到 GitHub Release 的完整操作手册RxAndroid 发布流程全指南从版本号管理到 GitHub Release 的完整操作手册 本文围绕 RxAndroid 官方仓库中的 RELEASING移动开发异步编程Taskwarrior 版本发布流程指南从 CmdNews 更新到 release tarball 与上游发布的完整操作手册Taskwarrior 版本发布流程指南从 CmdNews 更新到 release tarball 与上游发布的完整操作手册 Taskwarrior命令行任开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考