Fix telepresence local dev flow and dependency resolution - #4
Open
phenix3443 wants to merge 11 commits into
Open
phenix3443 wants to merge 11 commits into
phenix3443 wants to merge 11 commits into
Conversation
phenix3443
marked this pull request as ready for review
April 15, 2026 07:44
phenix3443
changed the title
chore: adopt dev branch strategy
docs: deduplicate agent instructions
phenix3443
changed the title
* docs: update branch strategy * ignore local agent instruction files
telepresence.sh 写死了 k3s 上的 ppanel-dev 命名空间。那个命名空间已经随 development overlay 一起删除，脚本现在指向不存在的东西，是坏的。 环境模型收敛成 develop / test / production 三个：develop 落在开发机的 compose.yaml 上，全部走 localhost、无域名、镜像只拉不推、数据库独立； test 在 k3s 的 ppanel 命名空间，由 womenlia/ppanel-deploy 管。 本地前端接管 k3s 流量这种跨环境调试不再保留。 - 删 telepresence.sh（我们自己加的，上游没有） - 两份 README 的 Telepresence 小节换成 develop 环境说明 只推 origin。upstream 从来没有过这个文件，不涉及上游。
chore: 废弃 telepresence 联调，develop 环境改用 compose
* feat(compose): develop 栈切 PostgreSQL，和 test 对齐 上游的 pg 支持是靠方言分支实现的（db.Dialector.Name() 散布在各 repo）， 本机跑 MySQL 就复现不了 test 上的方言问题——而那正是本机栈存在的意义。 - ppanel-db 换成 postgres:17.11-alpine（和 test 同版本），端口 5432 - config/ppanel.yaml 的 MySQL: 换成 Database:，Driver/Config 照抄 test 上 已经跑通的那份。上游把 MySQL: 标为 Deprecated，仍能读但走兼容路径 - README 两版都标注：./db 里是 MySQL 数据目录，Postgres 拒绝往非空目录 初始化，升上来要先删掉 * feat(compose): 从本地源码构建，修好前端端口映射 接着切 Postgres 那个提交，把 develop 配成真正能开发的环境。 - 三个服务都改成 build 相邻仓库的源码（PPANEL_SERVER_PATH / PPANEL_FRONTEND_PATH 可覆盖），不再拉上游 ppanel/*:latest——那些镜像里 没有我们 fork 的任何东西，拿它开发等于没跑 - 前端端口 3000 → 80：从 Next.js 迁到 Vite + nginx 之后容器里监听的是 80， 这两行一直没跟着改。表现是容器 Up 着但端口不通，日志里没有任何错误 - 删掉 NEXT_PUBLIC_API_URL：Next 时代的遗留，Vite 是构建期内联 VITE_*， 运行时设它没有任何作用 实测（docker 已启动）：整栈起来，迁移跑完、管理员建好、8080 监听， 三个入口 200，登录拿到 token，fork 独有的 /v1/admin/server/node/versions 返回 200 且带 min_self_manageable——证明跑的是我们的代码不是上游。 CORS 放行 localhost:3001，preflight 204。 * chore: 把误提交的 Postgres 数据目录移出版本控制 上一个提交里混进了 db/——docker compose up 生成的 Postgres 数据目录， 1940 个文件，还包含库里的真实数据。.gitignore 里没有它，一个 git add -A 就全带进去了。 同时补上 db/ 和 cache/ 两条忽略规则，避免再次发生。 （本分支是 squash 合并，这些文件不会进入 main 的历史。）
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
telepresence.shresolve the real k3sppanel-serverdependency config fromppanel-secretinstead of assuming hardcoded local MySQL and Redis endpointsup frontendrouted to the k3s backend through same-domain/apirequestsppanel-devquota, and document the new behavior in both READMEsRoot Cause
The previous script mixed together frontend and backend dependency assumptions, hardcoded MySQL and Redis targets, and inherited frontend API settings that could point at
127.0.0.1:8080even inup frontendmode. In the tested cluster, default Telepresence traffic-agent CPU limits also exceeded the remaining quota, which blocked intercept creation.Validation
bash -n telepresence.sh./telepresence.sh up both --frontend adminppanel-secretand port-forwarded them locally before starting the local serverup frontendsemantics aligned with same-domain/apirouting to the k3s backendtelepresence helm upgradeapplied reduced traffic-agent resources and that bothppanel-serverandppanel-admin-webreachedACTIVEintercept state afterwardImpact
up frontendnow behaves like a true frontend-only replacementup serverandup bothnow reuse the actual k3s dependencies by default instead of requiring separately prepared local database endpointsppanel-devenvironment