|
|
e6c8c3c155
|
feat(部署): deploy.sh 识别「自带数据」形态，不再写死试跑假设
Deploy / deploy (push) Has been cancelled
旧 Django 后端下线后要把 postgres / redis 收回 OJ2 自己的 compose 管。
compose 那边本来就备好了（oj-postgres / oj-redis 挂在 local-data profile 下，
镜像和旧栈同版本），但 deploy.sh 三处都写死了「并行试跑」的假设，会直接挡住：
- COMPOSE 没有 --profile local-data，自带的两个容器永远不会被启动
- 自检② 见到 DATABASE_URL 指向 oj-postgres 就 die —— 而合并后它必然指向那里
- 自检④ 要求已经有 oj-postgres 在跑 —— 旧的停了、新的还没起，正好卡死
现在按 DB_HOST 是否为空自动判形态。判据用 DB_HOST 而不是另加开关，是因为它本来
就决定了 DATABASE_URL 指向谁；两个变量各说各话迟早会出现「起了自带的库、却连到
别处」这种自相矛盾的状态。
自检② 改成两个方向都查：外接形态下不许指向 oj-postgres，自带形态下必须指向
`oj-postgres:5432`。连端口一起查是因为清了 DB_HOST 却忘了清 DB_PORT 会拼出
`oj-postgres:5445` —— 那是宿主机映射端口，容器网络里不通。
新增自检②b：自带形态下检查 $DATA_DIR/postgres/PG_VERSION 存在且是 16。
这是整个部署里唯一会**静默**走歪的地方 —— DATA_DIR 不对的话 postgres 当成全新
部署，在空目录上初始化一个空库，站点起得来、能注册能登录，就是一道题都没有。
验证：用模拟的 env 跑 `docker compose config` 确认
--profile local-data → 服务多出 oj-postgres / oj-redis
DATABASE_URL → postgres://onlinejudge:...@oj-postgres:5432/onlinejudge
REDIS_URL → redis://oj-redis:6379
卷 → /root/OJDeploy/data/{postgres,redis}（旧栈同一批目录）
并验证了「清了 DB_HOST 但忘清 DB_PORT」会被自检②拦下、正常配置会放行。
形态判定对空值 / 非空值 / 缺失三种情况都试过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 08:19:28 -06:00 |
|
|
|
586c88f629
|
build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留
Deploy / deploy (push) Has been cancelled
一条线上的三件事：让 drizzle 的迁移机制真正可用 → 用它加索引 → 用它清掉
不再需要的 Django 表，最后接进部署和 CI。
## 1. 让 drizzle-kit generate 可用
原本以为不能用：只加一个索引，generate 却吐出一堆噪音，其中 5 条
`DROP SEQUENCE auth_*/django_*` 打到生产库上会直接搞坏旧后端。
逐个查下来全是 `pull` 出的基线自己不能 round-trip，都是可修的：
- **快照里的 Django 序列**：tablesFilter 只过滤表、不过滤它们的序列。
已从 0000_snapshot.json 清掉。
- **bigint 上限精度**：pull 生成的 `maxValue: 9223372036854775807` 是 JS
number 字面量，round-trip 成 ...776000，每次 generate 都多出 10 条
ALTER COLUMN。改成字符串。
- **表达式索引的 opclass**：problem_tag_name_ci_unique 在快照里带
opclass，drizzle 自己序列化不出来，导致每次 drop + recreate。已去掉。
改完 `generate` 是干净的 no-op。
两个改不掉、只能绕的写进了 CLAUDE.md：索引 `.desc()` 生成 SQL 时会被丢
（单列索引不写方向即可，Postgres 用 Index Scan Backward 服务 ORDER BY
DESC，实测同样 0.08ms）；migrator 把所有语句包一个事务，
CREATE INDEX CONCURRENTLY 跑不了。
最容易吃亏的是 drizzle 没有 --fake-initial：对已有数据的库直接 migrate
会从 0000 跑起、撞表回滚，**而且 exit 1 但一个错误都不打印**。
## 2. 0001 提交列表索引
`WHERE contest_id IS NULL ORDER BY create_time DESC LIMIT n` 用不上现有的
contest_create_time_idx (contest_id, create_time DESC) —— Postgres 不把
`IS NULL` 当成能吃掉首列、从而继承第二列有序性的等值条件。把
enable_seqscan / enable_bitmapscan 全关掉逼它用也不肯，宁可走单列
contest_id 索引再全量排序。于是每翻一页都 Parallel Seq Scan 扫完整张表。
换成部分索引后谓词由索引自己保证，索引序就是查询要的排序序。生产快照
（12.3 万条提交）实测首页取 10 行：61.8ms / 读 18936 blocks →
0.22ms / 读 34 blocks。端到端 94ms → 6ms。
真正要命的不是单次 61ms，是每个请求都要把 169MB 的表刷一遍
shared_buffers —— 一节课几十个学生同时开提交列表，磁盘和缓存直接被打穿。
## 3. 0002 删掉 Django 残留
确认旧 Django 后端不再使用、也不再作为回滚路径。删前核实过：没有任何
OJ2 保留的表引用这 7 张，3 条外键全在它们内部（所以不用 CASCADE，真有
漏网的会报错而不是被悄悄级联掉）；5 个序列都由各自的表 owned，随
DROP TABLE 一并消失；数据全是 Django 自身元数据。tablesFilter 随之移除。
**回滚路径就此作废** —— CLAUDE.md 开头和 runbook 的「回滚保证」「七、回滚」
都改了。这条迁移已在本机 dev 库和生产快照副本上跑通，**生产库尚未执行**。
## 4. migrate 接进部署与 CI
deploy.sh 在构建之后、起栈之前跑 `oj2-api migrate`，失败就中止部署（旧
容器原样还在跑）。CI 走的也是 deploy.sh，所以不用给 GitHub 配数据库凭据，
也不用把生产库对外开放。
迁移文件**不内嵌进二进制**，随镜像装在 /usr/local/share/oj2/migrations。
这样 drizzle 的 migrate() 能原样用 —— 靠 _journal.json 自动发现，新增迁移
不用改任何代码，和 Django 扫 migrations/ 是一回事。内嵌就得为每条迁移
手写一行 import，那是迟早会漏的账。（CLAUDE.md 里「单二进制不能读文件」
那条讲的是 node_modules 和 import.meta.dir 推路径，按显式绝对路径读一个
数据目录不在此列。）
三道闸门，都是写完测出来才补上的：
- **破坏性迁移拦截**：DROP TABLE / DROP COLUMN / DROP SCHEMA /
ALTER COLUMN ... TYPE / TRUNCATE 命中就退出 4，需要
`OJ2_ALLOW_DESTRUCTIVE=1` 显式放行。DROP INDEX / DROP CONSTRAINT 不算，
拦了只会让人习惯性带上放行开关。扫描前先剥注释，避免误报。
- **基线缺失**：退出 3 并直接打印该敲的 SQL。注意判的是
`max(created_at) < 0` 而不是「表不存在」—— 表存在而为空（上次迁移失败
留下的）同样是没基线。
- **迁移目录读不到**：这是最可能犯的错（Dockerfile 漏拷），原本是 drizzle
的堆栈，现在直接说该检查哪一行。
另外发现 0000_crazy_gateway.sql 是 pull 的产物，**整份被 /* */ 包着，
可执行语句 0 条**，所以这个库根本不能靠迁移自举建表。原先写的「空库就从
0000 建」跑起来会炸在一个和真实原因毫不相干的 unterminated /* comment 上。
现在如实说明：结构只能来自 docs/specs/schema.sql 或生产 dump。
验证：镜像内编译（ARTIFACTS=build）出的真实镜像跑完五种场景 —— 拦截、
放行、幂等、无基线、漏拷目录，全部符合预期；dev 形态同样五种场景全过。
tsc / 路由遮蔽 / deploy.sh 语法 / generate no-op 都通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 07:56:30 -06:00 |
|
|
|
ed9d9f65bf
|
chore(部署): deploy.sh 结尾别再把 NPM 当待办事项
Deploy / deploy (push) Has been cancelled
反代早就配好了，每次部署完还提示「还差 NPM 那一步」是噪音。改成只报站点
地址，把 Websockets Support / client_max_body_size 200M 降级成「别关」的
提醒 —— 只有改 WEB_PORT 时才需要回 NPM 动一下。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 18:36:08 -06:00 |
|
|
|
6356643cc9
|
ci(部署): 部署走 GitHub Actions，产物挪到 runner 上编
Deploy / deploy (push) Has been cancelled
服务器性能差，镜像 builder 阶段（1238 个包的 bun install + bun compile +
vite build）首次约 5 分钟，光前端就 160s。改成在 runner 上编好 dist/oj2-api
和 apps/web/dist，rsync 过去，服务器那边只剩几条 COPY。
服务器自己编的能力没有砍掉。Dockerfile 顶部加了全局 ARG ARTIFACTS：
build（默认） builder 阶段自己编，只要有 docker 就能手动部署
prebuilt 用构建上下文里现成的产物，builder 不进构建图
实现是两个 scratch 阶段归一成 /artifacts/ 布局，再用变量阶段名
FROM artifacts-${ARTIFACTS} 选一个，运行时阶段不关心产物是谁编的。
deploy.sh 加 --prebuilt：产物缺失在自检就 die；顺带检测 buildx —— 没装的话
compose 会退回 classic builder，那个不看依赖图、所有阶段挨个跑，产物白编
（结果正确但不省时间），黄字提醒不阻断。
.dockerignore 末尾放行两个产物路径，必须在 dist/ 那些规则之后，
dockerignore 是最后一条匹配说了算。
顺手删掉 apps/web/.github/ —— 从 ojnext 抄来的残留，路径不对（GitHub 只认
仓库根的 .github/workflows/）从来没跑过，内容也是 ojnext 的。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 18:30:22 -06:00 |
|
|
|
e060327de4
|
fix(部署脚本): sh docker/deploy.sh 会挂在 pipefail，自己换 bash 重跑
Debian 的 /bin/sh 是 dash，没有 pipefail，一上来就 `Illegal option -o pipefail`。
在 set 之前加一行守卫，非 bash 就 exec 换 bash 重新执行（只用 dash 也认的语法）。
实测：本机 /bin/sh 指向 bash，所以这条得在容器里的真 dash 上验 ——
带守卫的版本正常往下跑（停在 docker/.env 不存在，因为只挂了脚本没挂仓库）；
去掉守卫的对照版本在 dash 下直接 Bad substitution + 语法错误。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-16 09:37:06 -06:00 |
|
|
|
eadfa0b04a
|
fix(部署脚本): 改成在服务器上直接跑，加 --check
上一版是从本机 rsync + ssh 过去的，不是想要的形态。改成服务器上跑：
代码怎么上去（rsync / 以后的 git pull）不归它管，脚本只管起栈。
五道自检，前两道是这次在服务器上真撞到的失败：
compose 版本 ≥ 2.20 depends_on.required 是那版才有的字段
DATA_DIR 卷指向 OJ2/data → 中止（空数据，且不报错）
DB_HOST DATABASE_URL 还指着 oj-postgres → 中止
JUDGE_STATE_DIR 没设的话新旧两个判题机共用运行目录
旧栈还活着 oj-postgres / oj-redis 是新栈的上游
--check 只做只读校验，不建目录不动容器（mkdir 挪到起栈那一段了）。
## 跑出来的两个问题
1. 版本比较写反了。原来用 `sort -V -C` 判「这两行本来就有序」，结果本机
compose 5.4.0 被判成「太老」。改成取 min(2.20, ver)，在 1.29.2 / 2.19.9 /
2.20.0 / 2.24.5 / 5.4.0 / 0 六个值上逐个验过分界。
2. --check 里的 mkdir 会真的建目录，本机跑直接撞权限。挪走了。
自检全路径实跑过：旧栈没起时正确拦下；造两个同名容器冒充旧栈后全绿通过；
抹掉 DATA_DIR / DB_HOST 两条守卫都按预期中止并打出可操作的提示。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-16 09:34:39 -06:00 |
|
|
|
eb849ca5ab
|
fix(镜像): apt 换清华源、去掉用不上的 ca-certificates；补部署脚本
## apt-get update 在服务器上卡死
不是慢，是挂住不返回 —— 本机构建从来没事，所以演练没暴露。换清华源。两个细节：
- trixie 的源是 deb822 格式，在 `/etc/apt/sources.list.d/debian.sources`，
老的 `sources.list` 在这个基底里是**空文件**，改它没有任何效果。
- **只能换主机名、必须保持 http。** https 源会在这一步失败，因为镜像里还没有根证书。
`ARG APT_MIRROR` 可覆盖。
## ca-certificates 是多余的
原注释写「给 AI 接口的 https 出站用」，不成立：Bun 和 Node 一样内嵌了一份根证书，
走自己那份，不读系统的 /etc/ssl/certs。
实测：把探针二进制丢进裸 debian:trixie-slim（没有 ca-certificates）请求
api.deepseek.com，握手正常、返回 401（没带 key），和装了的镜像行为一致。
去掉之后重新构建，clang-format / ruff 都在，https 出站照旧，487MB → 483MB。
哪天镜像里加了用 OpenSSL 做 TLS 的东西（curl、wget 之类），这条要重新考虑，
注释里写了。
## docker/deploy.sh
没有 git remote 时的部署路径：本机 rsync 推代码 → 服务器上构建 → 起栈 → 冒烟。
默认不推 docker/.env（两边不是一回事，覆盖掉是静默故障），要同步显式 --env。
起栈前两道守卫，就是今天在服务器上真撞到的那两种失败：DATA_DIR 没生效（卷指向
OJ2/data）、DB_HOST 没生效（DATABASE_URL 还指着试跑形态下并不存在的 oj-postgres）。
两道守卫都用当天那份坏 env 正反跑过：齐全时放行，抹掉这两个变量时都触发。
两半的语法也都 `bash -n` 过（远端那半是 heredoc，单独渲染后再查的）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-16 09:30:50 -06:00 |
|
