Files
danyang-match/.gitignore
WorkBuddy b624c43432 fix(ci): 依据 Actions 真实日志修复三处失败(runner 无 pnpm / 门禁缺依赖 / 生产配置未入库)
上一轮已把 CI 跑起来并读到真实结果:7 个 job 中 Mini Program 与 Test Shell Guard
通过,Admin Web、Backend、UI Contracts 三个失败,migration 与 e2e 因依赖 backend
被跳过。本轮全部依据 Actions 原始日志定位,而不是本地推测 —— 三者都不是业务代码问题。

1. Admin Web Build:runner 已不再预装 pnpm
   日志:Unable to locate executable file: pnpm
   runner 镜像(ubuntu-24.04 / 2.337.0)的 PATH 里没有 pnpm,而 setup-node 的
   cache: 'pnpm' 在 restore 阶段就需要调用 pnpm 可执行文件,于是 job 在第一步失败、
   后续步骤全部 skipped。同批的 miniapp job 没配 cache 所以正常通过,正好反向印证。
   改为先用 corepack 启用并钉住 pnpm@9.15.9,store 缓存改由 actions/cache 手动配置
   (此时 pnpm 才存在于 PATH)。

2. UI Contracts:门禁依赖没装
   日志:Cannot find module '.../miniapp/node_modules/typescript/lib/typescript.js'
   phase04 守卫会用 TypeScript 编译器 API 解析小程序源码,但本 job 此前不装依赖。
   本地能跑通只因为工作区早已装过;CI 的每个 job 都在独立 runner 上,
   miniapp job 安装的依赖不会共享过来。补上 npm install,并修正 workflow 中
   「零 npm 依赖、故无需装依赖」的错误注释 —— 与实际不符的声明本身就是缺陷来源。

3. Backend:断言了一个永远不会入库的文件
   日志:DeploymentTests.testDockerComposeProdExists 期望 true 实际 false
   infrastructure/docker-compose.prod.yml 被 .gitignore 列在
   「Secrets and certificates」段而排除出版本控制,但这是**误分类**:
   该文件不含任何明文密钥,敏感值全部走 ${VAR} 注入、db 密码走 Docker secrets,
   文件头注释本身也写着「敏感信息通过 .env 文件注入,不进 Git」。
   后果是该测试「本地恒绿(文件在工作区)、CI 恒红(checkout 拿不到)」,
   且从本地永远发现不了。现修正 .gitignore 把它纳入版本控制;
   真正的密钥仍由 secrets/、certs/、backups/ 等规则挡住。

修复后,此前因 backend 失败而被跳过的 migration 与 e2e 两个 job 也会真正跑起来。
2026-09-22 10:54:24 +08:00

92 lines
2.7 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Dependencies
node_modules/
backend/local-maven/
backend/build-temp/
backend/.m2/
__pycache__/
*.py[cod]
*.lock
package-lock.json
yarn.lock
pnpm-lock.yaml
# 例外:依赖锁文件必须入库,CI 的可复现安装依赖它们。
#
# 2026-09-22 修复背景:上面四条规则此前把 admin-web/pnpm-lock.yaml 与
# miniapp/package-lock.json 一并挡在版本控制之外,于是 CI checkout 后的环境
# 与本机完全不同:
# - admin-web:`pnpm install --frozen-lockfile` 找不到 lockfile → 直接失败
# (frozen 模式的语义就是「必须存在且不可变更」,缺文件不是警告而是错误);
# - miniapp:`npm install` 无 lockfile 约束,版本随上游浮动,
# `npx tsc --noEmit` 的结果不与任何一次本地验证对齐。
# 二者共同导致「本地绿、CI 红」且二者都不可解释。
#
# 只放行每个包真正使用的那把锁:admin-web 走 pnpm,miniapp 走 npm。
# admin-web/package-lock.json 仍然忽略 —— 同一目录并存两把锁会让两种包管理器
# 各自按自己的锁安装,漂移时彼此看不出问题,属于典型的双锁冲突。
!admin-web/pnpm-lock.yaml
!miniapp/package-lock.json
# Build outputs
backend/target/
admin-web/dist/
miniapp/dist/
miniapp/unpackage/
# vite 在 dev server 被强杀(未优雅退出)时会遗留配置临时文件
admin-web/vite.config.ts.timestamp-*.mjs
# IDE
.idea/
.vscode/
*.iml
*.iws
*.ipr
.DS_Store
# Environment variables with secrets
backend/src/main/resources/application-dev.yml
*.env
!.env.example
# Logs
*.log
logs/
# Test data
.pytest_cache/
tests/fixtures/*.csv
tests/fixtures/*.json
# Local workspace and developer settings
.worktrees/
.zcode/
.workbuddy/
project.private.config.json
/nul
/infrastructure/nul
# OS files
Thumbs.db
.DS_Store
# Secrets and certificates
#
# 2026-09-22 修正:`docker-compose.prod.yml` 原先被列在本段(当作密钥)而排除出
# 版本控制,这是**误分类** —— 该文件不含任何明文密钥:所有敏感值都通过
# `${VAR:?请设置...}` 注入,db 密码走 Docker secrets(./secrets/db_password.txt),
# 文件头注释本身也写着「敏感信息通过 .env 文件注入,不进 Git」。
#
# 后果:backend 的 `DeploymentTests.testDockerComposeProdExists` 断言该文件存在,
# 于是「本地恒绿(文件在工作区)、CI 恒红(checkout 拿不到)」——
# 一次典型的本地绿/CI 红假绿,且从本地永远发现不了。
# 生产部署配置需要可复现、可评审,应与 staging 版一致纳入版本控制。
# 真正的密钥仍由下面三条挡住。
infrastructure/secrets/
infrastructure/certs/
infrastructure/backups/
# Local artifacts and backups
artifacts/backups/
*.dump
*.bundle