4 Commits

Include renames

Author	SHA1	Message	Date
butubb	e348de48d3	feat(upstream): 上游更新检查——定期比上游、落后了推企业微信 ... 本仓库在上游 MediaCrawler 之上加了一整层（见 UPSTREAM.md），可合并流程默认 「有人知道上游动了」。而部署是 git pull --ff-only，只从自己的 Gitea 拉——上游的 提交不主动 fetch 就永远看不见。拖着不合并的代价是复利的：越久越难合。 于是把「上游动了没有」变成一条会自己跑、会推企业微信的通知： * api/monitor/upstream.py：git fetch <url> <branch> 到 FETCH_HEAD，用 rev-list --count HEAD..FETCH_HEAD 算落后数、FETCH_HEAD..HEAD 算领先数。 用 git 而非托管商 API，因为只有 git 知道共同祖先在哪——本仓库含有上游没有的 提交，直接比 tip 会得出错误结论。增量 fetch 只传几个新提交，不会遇到 UPSTREAM.md 里说的「大包必断」。 * 只 fetch 到 FETCH_HEAD：不配 remote、不写 refs/remotes、不碰索引与工作区， 所以不打断正在跑的采集，也不和 deploy.sh 的 git pull 抢锁。 * 挂在调度器 tick 上（不是采集，所以不看 is_busy、不受活跃时段限制——定时检查 放在半夜反而最合适），按 checked_at + 间隔 到期才跑；失败也写 checked_at， 于是 GitHub 不通时是每间隔重试一次，而不是每个 tick 撞一次墙。 * 同一个 tip 只推一次（记 tip 而不是「推过没」），上游真又动了会再推。 * 两个接口：GET /monitor/upstream 只读缓存；POST /monitor/upstream/check 手动 查一次且刻意不推通知——点按钮的人正看着结果。 * 默认关闭，间隔默认一天。 Dockerfile 显式装 git（python:slim 不带，而这是唯一的依赖）；deploy.sh 顺带补上 一个真 bug 的提示：Dockerfile/requirements.txt 变了只 up -d 用的还是旧镜像。	2026-10-10 09:17:06 +08:00
butubb	c1068845a9	fix(deploy): 部署时必须强制重建容器 ... 代码是 bind mount，容器配置与镜像都没变，所以裸的 `docker compose up -d` 会判定无需变更直接跳过，改了 .py 也不会生效。前端产物是磁盘上的静态文件、能即时生效，这一点很容易把问题盖住，直到有人改了后端代码才发现。 首次实测即命中：跑 deploy.sh 的输出是 'Container mediacrawler Running'，没有重启。	2026-10-07 15:22:00 +08:00
butubb	fe45442b01	chore: deploy.sh 标记为可执行（Windows 上创建的文件没有 exec 位）	2026-10-07 11:14:13 +08:00
butubb	74a592024c	feat: 部署改为 git 驱动，容器以宿主用户运行 ... 服务器实测可经 Cloudflare 443 访问 Gitea 且 git 协议正常（此前我只测了 13000 端口就断言不可达，是错的），因此不再需要 tar + SFTP。 - docker-compose: 增加 user: "1000:1000"。容器此前以 root 运行，写进挂载目录的每轮 jsonl 产物都是 root 属主，导致宿主用户连自己的部署目录都挪不动 —— 这在把部署迁到 /mnt/data 时实际发生了 - deploy.sh: 一条命令走完 拉代码 →（webui/ 有改动时）重建前端 → 重启容器。前端产物 api/webui 是 gitignore 的，git pull 带不过来，必须在服务器上重建一次 - Dockerfile: 补 npm 包。corepack 只管 yarn/pnpm 不管 npm，而前端要在服务器上重建；这样服务器只需要 Docker，不必另配 Node 环境	2026-10-07 11:13:43 +08:00