xuyue/OJ2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
252 Commits 1 Branch 0 Tags
f6995c841b30fdaff5ffaff7f2741a632770718a
Commit Graph
8 Commits
Author SHA1 Message Date
xuyueandClaude Opus 5 4c0c38445c fix(时区): 日历口径收回东八区，读出的时刻统一成 ISO 并保留微秒 
旧栈 Django 按 Asia/Shanghai 算日历，OJ2 重写时这个锚点丢了：容器和数据库会话
都是 UTC，于是「今日提交」在北京时间 0–8 点是空的，「凌晨/早起提交次数」整体偏
8 小时，热力图、AC 趋势年份、近两年活跃人数也各按进程时区切。

- 新增 apps/api/src/time.ts 作为唯一锚点（固定 +8 偏移，不依赖进程 TZ / tzdata），
  todayStart、成就小时/日期键、热力图、月份平移、年份夹逼全部改走它；
  SQL 里按日历切的一律显式 at time zone。
- db/index.ts：连接会话时区设为东八区（兜底）；给 timestamptz(1184) 挂 parser，
  读出统一成 ISO 8601 UTC，撤掉为拿 PG 文本形状写的 ::text。parser 保留微秒 ——
  生产库 12.3 万条提交几乎全带微秒，截成毫秒会让翻页分界行和班级 AC 排名的
  <= min(create_time) 把自己排除（翻页每页丢一条、排名少 1）。
- 前端 parseTime/zonedParts/zonedYear 按 Asia/Shanghai 渲染，n-date-picker 做
  toPickerValue/fromPickerValue 平移，站内不再按浏览器时区取时间部件。
- Dockerfile 设 TZ=Asia/Shanghai 作为第二道兜底。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-09-14 05:55:17 -06:00
xuyueandClaude Opus 5 f00c941ede perf(构建): builder 分开拷源码，只改后端不再陪编一次前端
Deploy / deploy (push) Has been cancelled
Details 
builder 阶段是 `COPY . .` 一把梭，而 docker 的层缓存是链式的：那一层的校验和
覆盖整个仓库，改任何一个文件都会把它作废，后面 vite build 和 bun compile 全部
重跑。前端那 160s 一次都躲不掉，改一篇 markdown 也要陪着编。

按各自的输入分开拷，慢的那条放前面（缓存链上越靠前越不容易被碰到）：

  只改 apps/api           前端两层命中缓存，只重编后端       ~1s
  只改 apps/web           前端重编，后端被链条带着            ~160s
  改 packages/contract    两边都重编（本来就都依赖它，是对的）
  改 docs / 根上的杂项    builder 根本看不见                  0

代价是 builder 只看得见这里点名拷进来的四样，新加顶层目录要同步加 COPY。

顺带堵掉两个同源的洞：

· apps/web/docs、tests、**/CLAUDE.md 进了 .dockerignore。它们在 apps/web 里面，
  整个目录拷进去的话，改一篇文档也会让 vite build 那层失效。

· .dockerignore 末尾为 --prebuilt 开的例外（!dist/oj2-api、!apps/web/dist）让本地
  产物照样进构建上下文 —— 这是比 `COPY . .` 更隐蔽的一条：在本机编一次后端，
  80MB 的 dist/oj2-api 变了，rsync 上去，服务器就重编一次前端，源码一行没动。
  dist/oj2-api 现在不再被 builder 拷贝；apps/web/dist 仍在 COPY apps/web 里面，
  所以 deploy.sh 头上那条手动 rsync 补了 --exclude dist。CI 走 --prebuilt，
  builder 整个不进构建图，不受影响。

验证：用老 Dockerfile 和新 Dockerfile 各构建一次 --target artifacts 导出对比，
后端二进制 sha256 相同，前端 dist 500 个文件逐个 sha256 一致。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-26 10:25:15 -06:00
xuyueandClaude Opus 5 586c88f629 build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留
Deploy / deploy (push) Has been cancelled
Details 
一条线上的三件事：让 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
xuyueandClaude Opus 5 6356643cc9 ci(部署): 部署走 GitHub Actions，产物挪到 runner 上编
Deploy / deploy (push) Has been cancelled
Details 
服务器性能差，镜像 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
xuyueandClaude Opus 5 604857b25e fix(一言): 接回真数据集，之前线上返回的是三条硬编码 
/quotes/random 在阶段 3 基线里只铺了个桩（三条写死的句子），读盘逻辑没移植，
所以 oj2.xuyue.cc 上一直是假数据——和 DATA_DIR 无关，哪儿部署都一样。

数据本来就在服务器上、位置也已经对上：旧栈挂 ./data/backend:/data，Django 的
HITOKOTO_DIR 就是它下面的 hitokoto/；OJ2 的 api 挂的是同一个目录。所以
Dockerfile 里跟着 TEST_CASE_DIRECTORY 写死 /data/hitokoto 即可，不用搬文件。

按分类懒加载并常驻，但只留前端用得上的 hitokoto/from 两个字段：原样缓存
7160 条要 2.5MB，裁完 1.4MB，而 api 容器只有 512m。读不到数据集时回落到
内置三条，不影响启动（本机 dev 默认就走这条）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 10:20:00 -06:00
xuyueandClaude Opus 5 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
xuyueandClaude Opus 5 f6bc42f534 docs: 给 OJ2 补一份自己的 CLAUDE.md；Dockerfile 拷上 bunfig.toml 
## bunfig.toml 没拷进容器，才是那批「本地能过、容器过不了」的根因

bunfig.toml 里设了 `linker = "hoisted"`，但 Dockerfile 只拷了 package.json 和
bun.lock，于是容器里用的是默认的 isolated 布局（包都在 node_modules/.bun/ 下），
本地靠"提升"才解析得到的包在容器里一律 Could not resolve —— 而本地构建始终是好的，
只有镜像构建才炸。之前是一个一个补直接依赖补过去的（那是对的、该保留），
这里让两边布局一致，是第二道保险。

带上之后装 622 个包（isolated 是 1238），镜像重建通过，二进制在容器里
serve + healthcheck 正常。

顺手补了 main.ts 帮助文本里漏掉的 healthcheck 子命令（compose 里把 command
写错时，看到的就是这行）。

## OJ2/CLAUDE.md

OJ2 是独立仓库，之前没有自己的项目指引。写了一份，重点是几条「不知道就会踩」的：

- **本机 Docker 可用**，整套依赖和上线演练都能在本机跑 —— 别沿用上一代
  "本机跑不起来后端"的旧假设
- 单二进制不能依赖 node_modules，`.node` 资源导入 dev 和编译两种形态行为不同，
  **改完两种形态都要跑**
- SQL 判题 spawn 的是二进制自己，入口必须有 argv 分发，那道递归闸不能删
- 判题状态码三处同步、raw_password 要保留、比赛只有 ACM、前端要兼容老 Chrome
- 不写迁移：新旧后端跑同一套表结构，这是回滚能成立的前提

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 03:37:45 -06:00
xuyueandClaude Opus 5 ea521e7b0a feat(阶段5): 镜像、三套 compose，前端切回 /api 与 /ws 
## 镜像

一个 Dockerfile 两个 target：api（单二进制）和 web（Caddy + 前端产物）。
旧后端是一个容器里用 supervisord 跑 caddy+gunicorn+dramatiq，这里拆成
oj-web / oj-api / oj-worker 三个容器 —— Docker 本身就是进程管理器，
拆开之后 worker 挂了能单独重启、日志也分得开，少一层 supervisord 要维护。

同一个镜像换个子命令就是 worker，镜像里只有一份运行时。
新增 healthcheck 子命令：运行镜像是 debian-slim，没有 curl/wget，
让二进制自己打 /health（只打 /health 不碰库 —— 库挂了该由库的 healthcheck 报，
不该让 api 跟着被判不健康然后被重启）。

**数据目录照抄旧后端**（test_case、public/upload、public/avatar）。
不是审美问题：切换那天不用搬动任何文件，回滚时旧后端立刻能找到自己的数据。
少一次几十 GB 的 mv，就少一个在停机窗口里出错的机会。

构建路上踩到三个坑，都是「本地能过、容器里过不了」那一类：

- 构建上下文吸进了 data/，judge_server/run 是判题沙箱用别的 uid 建的，
  docker 连 stat 都做不了，构建直接失败 → 补 .dockerignore
- mermaid@9.4.3（机房老 Chrome 的 legacy 依赖，不能砍）从容器里连
  registry.npmjs.com 稳定失败，主机上没问题 → 换 npmmirror，并重试两次
- 容器里 bun 用 isolated 布局，本地是扁平的。靠「提升」才能解析到的包
  在容器里一律解析不到：@node-rs/jieba-linux-x64-gnu（编译要 import 它的 .node）、
  以及前端的 @codemirror/{language,state,view} 和 @lezer/highlight。
  这些本来就是代码直接 import 的，补成直接依赖。顺手写了个脚本扫全仓，
  确认只有这 4 个。

## 前端切回 /api、/ws

迁移期用 /api2、/ws2 指新后端，/api、/ws 还指着 Django。端点已全部搬完，
临时前缀去掉。改动只有三处（api2.ts 的 baseURL、websocket.ts 的两个 URL），
`api2` 那些 import 是模块名不是路径，不动。vite 代理同步收敛成三条。

## compose

- debian：全套（含 postgres，对外开 5445 给机房连）
- school：**没有 postgres**，连服务器的库；本地 Redis + 本地判题沙箱
- 两边共用一个库但各有各的队列和 WS 推送，和旧后端的 Dramatiq/Channels 拓扑一致

密钥一律走 env 且带 `:?`，没设置就直接报错退出，不静默用弱默认值。
COOKIE_SECURE 在机房必须是 false（http 直连 IP，带 Secure 的 Cookie 发不回来，
表现是「登录成功但立刻又变未登录」）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 23:41:20 -06:00