Kubeapps 测试体系全解析：从本地环境搭建、CI 配置到端到端浏览器测试-开发者社区

云原生
后端
前端

【免费下载链接】kubeapps

A web-based UI for deploying and managing applications in Kubernetes clusters

项目地址：https://gitcode.com/gh_mirrors/ku/kubeapps

Kubeapps 是一个运行在 Kubernetes 集群中的开源 Web UI，用于部署和管理集群中的应用。为了保证从源码到发布版本的可靠性，Kubeapps 建立了一套覆盖"单元测试 → 构建镜像 → 集成测试 → 发布"全链路的测试体系。本文以官方 Testing Reference 及其三个子文档（环境搭建、CI 配置、端到端测试）为骨架，结合仓库中的实际脚本与工作流源码，系统讲解如何搭建与第三方服务（如 Harbor）联调的测试环境、理解 GitHub Actions 驱动的 CI 流水线，以及如何本地运行基于 Playwright 的浏览器端到端测试。

一、测试体系总览：三份文档各司其职

site/content/docs/latest/reference/testing/目录下的测试参考文档分为三个部分，分别解决"在哪儿测、怎么自动化测、怎么端到端测"三个问题：

文档	核心内容
testing-environment.md	在本地 K8s 集群中搭建 Kubeapps 与第三方服务（目前支持 Harbor）的联调测试环境
ci.md	Kubeapps 基于 GitHub Actions 的 CI 配置，包括工作流、任务、凭据与排错方法
end-to-end-tests.md	基于 Playwright 的浏览器端到端测试，本地运行方式与 CI 运行方式

二、搭建 Kubeapps 集成测试环境（Testing Environment）

2.1 背景与前置条件

Kubeapps 可以通过与第三方服务集成来扩展能力，典型场景是接入私有包仓库（Private Package Repositories），详见 howto/private-app-repository.md。为了便捷地复现这类集成场景，官方提供了一组自动化脚本，可以在 K8s 集群上同时装好 Kubeapps 与待集成的服务。

搭建前需要准备：

一个可用的 Kubernetes 集群（官方推荐使用 Kind 快速创建）；
kubectl 命令行工具；
Helm 客户端。

2.2 脚本清单与职责划分

测试环境脚本存放在 site/content/docs/latest/reference/scripts/ 目录，当前支持Kubeapps × Harbor一种集成组合。脚本职责如下：

脚本	职责
setup-kubeapps.sh	创建命名空间、安装 Kubeapps Helm Chart、等待组件就绪、创建示例 ServiceAccount 与 RBAC
setup-harbor.sh	创建命名空间、安装 Harbor Helm Chart、等待组件就绪
setup-kubeapps-harbor.sh	前两者的包装脚本，一键完成"Harbor + Kubeapps + 初始仓库"的联动安装
delete-kubeapps.sh	卸载 Kubeapps 及其关联的命名空间、RBAC 资源
delete-harbor.sh	卸载 Harbor 及其关联的命名空间、PVC
delete-kubeapps-harbor.sh	一键清理通过`setup-kubeapps-harbor.sh`搭建的环境

所有脚本都通过--help或-h参数输出用法说明，例如：

./setup-kubeapps.sh --help ./setup-harbor.sh --help

2.3 setup-kubeapps.sh 的参数与行为

从 setup-kubeapps.sh 的print_menu可以看到该脚本支持的参数：

参数	说明
`-n, --namespace [namespace]`	Kubeapps 安装的命名空间，默认`kubeapps`
`--initial-repos [repo_name repo_url]`	预置到 Kubeapps 的初始应用仓库（name + url），可重复使用多次；默认预置`bitnami https://charts.bitnami.com/bitnami`
`-u, --dry-run`	只打印将要生成的 values.yaml，不实际安装
`-h, --help`	打印帮助菜单

脚本的关键行为（见 setup-kubeapps.sh）：

根据--initial-repos动态生成 values.yaml，写入apprepository.initialRepos列表（每个仓库包含name与url两个字段）；
通过helm install kubeapps从oci://registry-1.docker.io/bitnamicharts/kubeapps安装，并指定useHelm3: true；
依次等待kubeapps、kubeapps-internal-apprepository-controller、kubeapps-internal-dashboard三个 Deployment 就绪；
在default命名空间创建名为example的 ServiceAccount，并绑定edit集群角色与kubeapps:kubeapps:apprepositories-write角色，用于测试应用仓库的读写权限；
输出端口转发命令与 API Token 获取命令，方便直接访问 Dashboard。

该脚本大量复用了 script/libtest.sh（如k8s_wait_for_deployment）和 script/liblog.sh（如info、silence）等公共库函数，说明这些环境脚本是构建在 Kubeapps 自身测试工具链之上的。

2.4 setup-harbor.sh 的参数与行为

Harbor 侧脚本（见 setup-harbor.sh）同样支持参数化：

参数	说明
`-n, --namespace [namespace]`	Harbor 安装的命名空间，默认`harbor`
`--disable-chartmuseum`	禁用 ChartMuseum 组件
`--disable-clair`	禁用 Clair（漏洞扫描组件）
`--disable-notary`	禁用 Notary（镜像签名组件）
`-u, --dry-run`	只打印生成的 values.yaml
`-h, --help`	打印帮助菜单

脚本会生成包含service.tls.enabled: false、chartmuseum.enabled、clair.enabled、notary.enabled的 values.yaml，通过helm install harbor（chart 源为oci://registry-1.docker.io/bitnamicharts/harbor）完成安装，随后按需等待harbor-core、harbor-jobservice、harbor-nginx、harbor-portal、harbor-registry以及可选的harbor-chartmuseum、harbor-clair、harbor-notary-server/harbor-notary-signer等 Deployment 就绪，最后输出 Harbor 的管理员用户名（admin）与从harbor-core-envvarsSecret 中解码得到的初始密码。

2.5 一键联动：setup-kubeapps-harbor.sh

官方推荐直接使用包装脚本 setup-kubeapps-harbor.sh，它做的事相当于：

# 1. 在 harbor 命名空间安装 Harbor（关闭 Clair 与 Notary） ./setup-harbor.sh --namespace "harbor" --disable-clair --disable-notary # 2. 在 kubeapps 命名空间安装 Kubeapps，并把 Harbor 的 Chart 仓库加入初始仓库列表 ./setup-kubeapps.sh --namespace "kubeapps" \ --initial-repos "harbor-library" "http://harbor.harbor.svc.cluster.local/chartrepo/library"

即文档所述三件事：

在harbor命名空间下安装 Harbor；
在kubeapps命名空间下安装 Kubeapps；
以 Harbor 服务的主机名（harbor.harbor.svc.cluster.local）为基础，将 Harbor 的 Chart 仓库作为初始仓库加入 Kubeapps（仓库名harbor-library、URL 指向/chartrepo/library）。

2.6 环境清理

卸载脚本与安装脚本一一对应：

delete-kubeapps.sh 依次执行helm uninstall kubeapps、删除example-kubeapps-repositories-writeRoleBinding、删除kubeapps命名空间、删除exampleServiceAccount 及example-editRoleBinding；
delete-harbor.sh 依次执行helm uninstall harbor、删除 Harbor 命名空间下的 PVC（避免残留数据卷）、删除harbor命名空间；
delete-kubeapps-harbor.sh 供使用setup-kubeapps-harbor.sh搭建的环境一键清理。

三、Kubeapps CI 配置深度解读（GitHub Actions）

3.1 CI 的整体目标与架构

Kubeapps 的 CI 基于GitHub Actions（GHA）构建，承担三类职责：

运行单元测试与集成测试；
构建并推送 Docker 镜像；
与官方 Bitnami Helm Chart（bitnami/kubeapps）双向同步。

一次向main分支推送 commit 后，成功的工作流形态如下图所示（该图出自 ci-workflow-main.png，为 CI 工作流执行结果示意）：

Kubeapps CI 主流水线工作流示意

GHA 配置涉及四个层次的概念：

Workflow（工作流）：即通常所说的 pipeline，是由多个 Job 组成的有向无环图；可在不同事件/条件下自动触发（如 main 分支提交、PR 创建），也支持手动触发、定时触发，以及被其他顶层工作流复用调用；
Job（任务）：由一系列按顺序执行的 Step 组成的逻辑单元（例如"运行单元测试"），每个 Job 运行在相互隔离的环境中（虚拟机或容器）；
Step（步骤）：GHA 中最小的执行单元，可以是调用一个 Action，也可以是执行一条或多条 shell 命令（包括调用脚本文件）；
Action（动作）：可复用的、负责执行特定任务的代码块，通常由多个 Step 组成。分为两类：
- 公开 Action：第三方开发、公开发布在 GitHub Marketplace 上的 Action（如actions/checkout），直接引用即可；
- 自定义 Action：项目自建、用于避免代码重复的 Action，定义在.github/actions/<action-name>/action.yml。

3.2 顶层工作流与可复用工作流

仓库.github/workflows/目录下的顶层工作流如下：

工作流	触发条件	说明
kubeapps-main.yaml	新建 PR、向`main`分支推送 commit	即"Main Pipeline"，内部调用`Kubeapps General`可复用工作流
kubeapps-release.yml	推送匹配`vX.Y.Z`的 tag	即"Release Pipeline"，内部调用`Kubeapps General`，并开启 GKE 测试与发布流程
kubeapps-full-integration.yaml	手动触发（Actions 页面）+ 定时（每周一、三、六 04:00）	即"Full Integration Pipeline"，调用`Kubeapps General`时传入`run_gke_tests: true`，在外部 GKE 集群上运行 e2e 测试
codeql-analysis.yml	多种事件/条件自动触发	CodeQL 安全分析；因耗时很长，独立于`Kubeapps General`工作流
ci-custodian-rules.yaml	定时运行	执行项目若干 custodian 规则（如清理未挂载磁盘）
add-issues-to-project.yaml	新 issue 创建	项目自动化：把新 issue 加入 Kubeapps 项目看板

可复用工作流（供顶层工作流调用）包括：

工作流	说明
kubeapps-general.yaml	整个流水线的核心定义，包含按不同条件（触发事件、仓库/分支）运行的多个 Job；接收输入参数（如是否运行 e2e 测试）以支持多场景
gke_e2e_tests.yaml	在 GKE 集群上运行 e2e 测试的 Job 定义
linters.yml	执行项目多个 linter 的 Job 定义

以 kubeapps-main.yaml 为例，其全部逻辑就是一句uses: ./.github/workflows/kubeapps-general.yaml并secrets: inherit，外加concurrency取消策略（同一分支新推送会取消进行中的旧运行）；kubeapps-release.yml 则在调用时传参run_gke_tests: true、run_linters: false、trigger_release: true。

3.3 自定义 Action：srp-source-provenance

当前项目只有一个自定义 Action：srp-source-provenance。它承载了生成并提交 source provenance 的逻辑，以满足 VMware SRP（Secure Release Pipeline，安全发布流水线）要求。由于该 Action 目录（.github/actions/srp-source-provenance/action.yml）在当前仓库中已被归档移除，此处以官方 CI 文档描述为准：自定义 Action 统一存放在/.github/actions/<action-name>/action.yml。

3.4 Kubeapps General 工作流中的 Job 全景

Kubeapps General工作流（kubeapps-general.yaml）中的主要 Job 如下：

Job	作用
`setup`	执行基础设置逻辑并生成供下游 Job 消费的输出数据。背景是 GHA 的限制：不能在某些上下文中直接使用环境变量（例如无法在 Action 调用的`with`块里直接传环境变量），也不能在`env`块中动态设置环境变量值，因此用该 Job 的 output 绕开
`linters`	直接调用存放所有 linter 的可复用工作流 linters.yml
`linters_result`	各 linter Job 虽定义在`linters.yml`中，但逐个作为分支保护规则的状态检查不现实，此 Job 作为全部 linter 的"总状态检查"
`test_go`	运行所有 Go 项目的单元测试（`make test`），并运行依赖数据库的测试（`make test-db`，CI 中以`bitnami/postgresql`service 容器提供数据库）
`test_dashboard`	运行 Dashboard 的 lint 与单元测试（`yarn lint`与`yarn test`）
`test_pinniped_proxy`	运行 pinniped-proxy（Rust 项目）的单元测试（`cargo test --manifest-path cmd/pinniped-proxy/Cargo.toml`），在`rust`容器中执行
`test_oci_catalog`	运行 oci-catalog（Rust 项目）的单元测试，需先安装`protobuf-compiler`
`test_chart_render`	测试 Helm Chart 渲染是否正常（安装最小与稳定两个版本 Helm 后运行 script/chart-template-test.sh）
`build_docker_images`	用矩阵并行构建多个组件镜像：`apprepository-controller`、`asset-syncer`、`kubeapps-apis`、`pinniped-proxy`、`oci-catalog`
`build_dashboard_image`	构建`dashboard`镜像
`build_e2e_runner_image`	构建用于运行集成/e2e 测试的镜像（`integration-tests`）
`push_dev_images`	将开发镜像推送到 Dockerhub。所谓"开发镜像"是指由特性分支任意 commit 产生的镜像；为避免污染 tag 历史，统一加`-ci`后缀，例如`kubeapps/dashboard-ci`。来自外部 fork 的 PR 因拿不到 secrets 而跳过此 Job
`local_e2e_tests`	在 GHA 环境内部运行 e2e 测试，详见下文；运行前会准备环境：安装 kind、kubectl、mkcert、helm 等二进制，拉起两个 Kind 集群，把 CI 镜像加载进集群，再执行 script/e2e-test.sh
`local_e2e_tests_result`	作为`local_e2e_tests`的全局状态检查。原因：`local_e2e_tests`用矩阵将测试并行隔离运行（carvel、flux、main 各分组等），而分支保护规则无法逐项检查矩阵 job，所以需要一个聚合 job
`push_images`	每当向 main 分支推送 commit 或创建版本 tag 时，把已构建好的 CI 镜像重新打 tag 并推送到 Dockerhub 的`kubeapps`账号（dev 镜像`-ci`后缀去掉，生产 tag 为`latest`或`vX.Y.Z`）
`sync_chart_from_bitnami`	每次向 main 分支推送 commit 时，把 Bitnami 上游 charts 仓库的最新改动同步到 Kubeapps 开发 Chart，过程见下文
`sync_chart_to_bitnami`	发布时（创建版本 tag）把 Kubeapps 开发 Chart 同步回 Bitnami charts 仓库，过程见下文
`release`	推送版本 tag 时，基于当前 tag 调用 script/create_release.sh 创建 GitHub Release
`gke_setup`	GKE 外部 e2e 测试的网关 Job：因为 GHA 限制无法用环境变量向可复用工作流传参，该 Job 把所需环境变量转成 output 数据，同时让依赖它的 Job 复用同一组执行条件
`GKE_[STABLE\\|REGULAR]_VERSION`	针对 GKE 支持的 Kubernetes 版本（stable 与 regular 两个发布通道）各有一个 Job，在对应版本 GKE 集群上运行 e2e 测试；若改动影响了 UI，此处可能失败

从源码看，local_e2e_tests矩阵包含 8 个分组：carvel、flux、main-group-1、main-group-2、main-group-3、multicluster、multicluster-nokubeapps、operators，与 integration/tests 目录下的测试分组一一对应。环境准备阶段会安装kind、kubectl、mkcert、helm，通过 create-kind-cluster.sh 与 create-additional-kind-cluster.sh 拉起两个 Kind 集群，再把 CI 构建产物镜像kind load image-archive进集群，最终由 run_e2e_tests.sh 包装环境变量后调用 e2e-test.sh。

3.5 Chart 双向同步与发布流程细节

sync_chart_from_bitnami（上游 → Kubeapps）的步骤为：

检查 Bitnami Chart 版本是否大于 Kubeapps 开发 Chart 版本，若不大于则停止；
删除本地chart/kubeapps目录（改动已提交在 git 中）；
克隆kubeapps-bot/chartsfork，拉取最新上游改动并推回 fork；
获取 Bitnami 提供的最新 Chart 版本；
把生产镜像（bitnami/kubeapps-xxx）重命名为开发镜像（kubeapps/xxx），tag 用latest；
使用DEVEL作为appVersion；
在 Kubeapps 仓库（从推送的分支）提交一个包含这些改动的 draft PR。

sync_chart_to_bitnami（Kubeapps → 上游，发布时）的步骤为：

检查 Kubeapps 开发 Chart 版本是否大于 Bitnami Chart 版本，若不大于则停止；
删除本地bitnami/kubeapps目录（改动已提交在 git 中）；
克隆kubeapps-bot/chartsfork，拉取最新上游改动并推回 fork；
获取 Kubeapps 提供的最新 Chart 版本；
把开发镜像（kubeapps/xxx）重命名为生产镜像（bitnami/kubeapps-xxx），tag 用vX.X.X；
使用vX.X.X作为appVersion；
从机器人账号的个人 fork 向 Bitnami Charts 仓库提交 draft PR。

需要特别说明的两点：

该同步流程与官方 Bitnami 镜像/Chart 的发布相互独立——Bitnami 镜像按其内部流程构建（不会使用本项目定义的 Go/Node/Rust 版本），若发生大版本升级需要人工协调；
每次发布新版 Chart 时，由 Kubeapps 团队负责向 Bitnami 的 Chart 仓库提交 PR。虽然sync_chart_to_bitnami自动化了整个过程，但维护者必须人工审查 draft PR 并转为正式 PR。

3.6 CI 凭据配置（Credentials）

除了通过 GHA 界面传入的常规 secrets 外，CI 还需要为机器人账号kubeapps-bot <tanzu-kubeapps-team@vmware.com>授予 commit 与 PR 权限，分三步：

Personal Access Token：用机器人账号创建，至少授予repo:status、public_repo、read:org权限，存入仓库Security > Secrets > Actions的GITHUB_TOKEN中。用于让 GitHub CLI 以机器人身份创建 PR，以及执行需要认证的 GitHub API 调用；
Deployment Keys（部署密钥）：添加到 CI 将要 push 的仓库（目前是vmware-tanzu/kubeapps与kubeapps-bot/charts）。让机器人账号能够远程推送分支；注意 CI 永远不会直接 push 到main分支，总是通过 PR 合入；
GPG 密钥对：公私钥分别存入GPG_KEY_PUBLIC、GPG_KEY_PRIVATE两个 secret；公钥还需上传到机器人账号的 GitHub GPG 设置中，用于签名该账号创建的 commit 与 tag。

此外，还需在Security > Secrets > Dependabot中添加DOCKER_PASSWORD与DOCKER_USERNAME，供 Dependabot 提交的 PR 触发的工作流使用；否则这些 secrets 不可用，GHA 无法把 Docker 镜像推送到 Dockerhub。从 kubeapps-general.yaml 的env中可以看到，CI 用到的相关常量包括CI_BOT_USERNAME: kubeapps-bot、CI_BOT_EMAIL: tanzu-kubeapps-team@vmware.com、CI_BOT_GPG以及两个部署密钥的文件名变量。

3.7 生成与配置部署密钥

该步骤只执行一次，很少变更，但了解它有助于应对密钥轮换等场景：

# 复制以下内容到 GitHub（需要写权限）： ## https://github.com/vmware-tanzu/kubeapps/settings/keys ssh-keygen -t ed25519 -C "tanzu-kubeapps-team@vmware.com" -q -N "" -f kubeapps-deploymentkey echo "Kubeapps deployment key (public)" cat kubeapps-deploymentkey.pub # 复制以下内容到 GitHub（需要写权限）： ## https://github.com/kubeapps-bot/charts/settings/keys ssh-keygen -t ed25519 -C "tanzu-kubeapps-team@vmware.com" -q -N "" -f charts-deploymentkey echo "Charts deployment key (public)" cat charts-deploymentkey.pub # 复制以下内容到 Kubeapps 仓库 `Security > Secrets > Actions` 的 `SSH_KEY_KUBEAPPS_DEPLOY` secret： ## https://github.com/vmware-tanzu/kubeapps/settings/secrets/actions echo "Kubeapps deployment key (private)" cat kubeapps-deploymentkey # 复制以下内容到 Kubeapps 仓库 `Security > Secrets > Actions` 的 `SSH_KEY_FORKED_CHARTS_DEPLOY` secret： ## https://github.com/vmware-tanzu/kubeapps/settings/secrets/actions echo "Charts deployment key (private)" cat charts-deploymentkey

3.8 调试 CI 错误

GHA 没有官方内置的 job SSH 调试手段，但可以借助第三方 Action（如lhotari/action-upterm）SSH 进入某个 job 检查日志、进程与目录。步骤如下：

在要调试的 job 中新增一个步骤：uses: lhotari/action-upterm@v1；
触发工作流（提交 commit 或手动触发），等待执行流到达该步骤；它会阻塞执行，等待入站 SSH 连接；
在lhotari/action-upterm的 job 输出中查看连接详情；
该 job 会一直阻塞，直到你退出 SSH 会话，或在工作目录下创建名为continue的文件。

四、端到端浏览器测试（End-to-End Tests）

4.1 测试定位与入口脚本

每次 CI 构建都会运行一组端到端测试，从用户视角尽可能验证改动没有引入回归。当前 e2e 测试全部是浏览器测试，由 script/e2e-test.sh 驱动，流程如下：

安装 Kubeapps：使用 CI 过程中构建的镜像（见 kubeapps-general.yaml），通过设置合适的 Helm 参数完成安装；若启用USE_MULTICLUSTER_OIDC_ENV，则追加一组多集群环境配置参数；
等待就绪：等待各 Deployment 就绪，并等待 bitnami 仓库的同步 Job 完成；
安装依赖：安装 ChartMuseum；非 GKE 环境额外安装 Operator framework（OLM）；
运行浏览器测试。

全部成功后将退出码交还 CI（通过 run_e2e_tests.sh 写入TEST_RESULT环境变量）。

从 e2e-test.sh 源码可以看到更多实现细节：

安装 Kubeapps 时通过installOrUpgradeKubeapps函数执行helm upgrade --install kubeapps-ci --namespace kubeapps，并为apprepository-controller、asset-syncer、dashboard、pinniped-proxy、kubeapps-apis、oci-catalog六个组件逐个--set image.tag与image.repository（dev tag 形如build-<sha>，镜像名带-ci修饰符）；
多集群场景会启用authProxy（OIDC 提供方为 Dex），配置clusters[1].name=second-cluster与额外的apiServiceURL、serviceToken；
ChartMuseum 安装后，脚本会把 Apache 8.6.2/8.6.3 等测试 Chart 改名（加kubeapps-前缀）后 push 进去，同时构建simplechart等本地测试 Chart；
测试矩阵支持all、main（及main-group-N子分组）、multicluster、multicluster-nokubeapps、carvel、flux、operators等分组，非 GKE 下执行main与multicluster分组，carvel/flux分组会先安装 kapp-controller/Flux 并把 Kubeapps 切换为对应的 packaging 后端，operators分组需安装 OLM 并开启featureFlags.operators=true。

4.2 测试目录结构与依赖

浏览器测试存放在自包含的 integration 目录中：

package.json 声明了全部依赖：@playwright/test（当前为^1.46.0）、axios，devDependencies 为prettier；test脚本即playwright test --workers=1；
Dockerfile 基于mcr.microsoft.com/playwright:v1.48.1-jammy构建，yarn install --frozen-lockfile后执行npx playwright install安装浏览器，最终容器常驻（tail -f /dev/null），测试代码与配置通过kubectl cp在运行时传入；
playwright.config.js 定义测试运行参数：globalTimeout由CI_TIMEOUT_MINUTES控制（默认 10 分钟）、单测timeout由TEST_TIMEOUT_MINUTES控制（默认 4 分钟）、retries: 2、headless 模式、失败时保留截图/视频/trace，reporter 输出到reports/目录；
测试用例按分组存放在 integration/tests 目录：carvel、flux、main-group-1、main-group-2、main-group-3、multicluster、multicluster-nokubeapps、operators，公共工具在utils子目录（如 kubeapps-login.js、util-functions.js）。

测试失败时，除了测试日志，还会在reports/screenshots目录生成截图。

4.3 本地运行浏览器测试

本地运行只需要两步：安装依赖、设置环境变量并启动测试。

cd integration yarn install INTEGRATION_ENTRYPOINT=http://kubeapps.local USE_MULTICLUSTER_OIDC_ENV=false ADMIN_TOKEN=foo1 VIEW_TOKEN=foo2 EDIT_TOKEN=foo3 yarn test

其中ADMIN_TOKEN、VIEW_TOKEN、EDIT_TOKEN对应拥有不同权限的测试账号 Token（e2e 脚本中会分别创建kubeapps-operator、kubeapps-view、kubeapps-edit三个 ServiceAccount 及其 Secret，并绑定相应 RBAC 后取出 Token 注入测试）。你也可以先用 setup-kubeapps.sh 在集群中装好一个配置好的 Kubeapps 实例。

4.4 在 Pod 中运行浏览器测试

CI 环境缺少运行浏览器测试所需的依赖，且为了提供可复现的环境，官方支持在 Kubernetes Pod 中运行浏览器测试：启动 kubeapps/integration-tests 镜像实例（该镜像包含全部依赖并常驻等待），把最新测试代码复制进镜像、运行测试，失败时从中取出截图。

构建并发布 kubeapps/integration-tests 镜像

CI 依赖该镜像运行浏览器测试，因此它必须正确版本化。镜像通过 integration/Makefile 构建，用IMAGE_TAG变量传入版本号：

# 先从 Docker Hub 获取最新 tag，然后将其 patch 版本 +1 作为 IMAGE_TAG cd integration IMAGE_TAG=v1.0.1 make build IMAGE_TAG=v1.0.1 make push

Makefile 中的build目标即docker build -t kubeapps/integration-tests$(IMG_MODIFIER):$(IMAGE_TAG) .，push目标即docker push。推送新镜像时，还要同步更新 package.json 中的version字段。

每当触发新的kubeapps/integration-tests版本（如更换 NodeJS 基础镜像、升级集成测试依赖等），完整流程为：

检查 integration/Dockerfile 是否使用正确的基础镜像版本；
确保 package.json 没有使用已废弃的依赖；
更新 integration/Makefile 中的版本 tag；
执行make build && make push发布新镜像版本。

五、总结：三份文档协同构成的测试链路

综合来看，Kubeapps 的测试体系是一条从开发到发布的全链路：

环境层（testing-environment.md）：用setup-kubeapps.sh/setup-harbor.sh/setup-kubeapps-harbor.sh在 Kind 集群中快速搭建 Kubeapps 与 Harbor 的联调环境，用对应的delete-*脚本一键清理；
CI 层（ci.md）：以 kubeapps-general.yaml 为核心，串联 lint、Go/前端/Rust 单元测试、Chart 渲染测试、镜像构建、本地与 GKE 上的 e2e 测试、Chart 双向同步与发布，并由kubeapps-bot机器人账号 + 部署密钥 + GPG 签名保障自动化提交与 PR 的凭据安全；
E2E 层（end-to-end-tests.md）：以 script/e2e-test.sh 为入口、Playwright 为执行引擎、integration 自包含目录为测试载体，既可在本地直接跑，也可用kubeapps/integration-tests镜像在 Pod 中可复现地运行。

对于希望为 Kubeapps 贡献代码或搭建类似测试体系的开发者，这三份文档连同仓库中的脚本与工作流，本身就是一套可以直接借鉴的完整参考实现。