926 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
QunLIn	f032310188	永久跳过海外直传 UpYun，国内线路全走中转机 ... 海外 runner 对 UpYun v0 接口无论什么参数都是 70 秒左右 EOF （-w 10/--strong 与 -w 3 均验证），3 轮重试全败，每次部署白耗 5 分钟（build #25 日志实锤）。 直传步骤改为 if: false 永久跳过（代码保留，将来 runner 挪国内 删掉该条件即可恢复）。国内线路由腾讯云广州中转机兜底：每分钟 比对 COS build hash → 下载产物 → upx sync → 又拍云 purge → 多吉云刷新（sync.sh 自带，CI 侧不再重复刷）。	2026-10-03 10:23:43 +08:00
QunLIn	cc85ace7c2	官职徽章改回主题渲染，数据由后端 rank 字段下发 ... 上一版把九品官阶塞进官方 badge_name/badge_color 槽——但博主 徽章是独一无二的，官职应该接在它后面而不是挤占同一个槽位。 后端现下发独立字段 rank_name/rank_title/rank_count/rank_color/ rank_bg（配色沿用主题原版彩字+半透明底），本文件在 comment-rendered 事件里渲染官职徽章。	2026-10-03 10:01:52 +08:00
QunLIn	20869a3c45	RSS API 地址全部收敛到 hugo.toml [params.rssapi]，切到 api.200181.xyz ... - 新增 [params.rssapi] base 配置，主题 7 处硬编码改为读配置： head(preconnect+window.rssApiBase)、footer(构建时拉 links/feeds)、 render-link(favicon)、circles/links 页 fetch、linkify.js(读 window.rssApiBase) - scripts/fetch_greetings.js 支持 RSS_API_BASE 环境变量，默认新地址 - scfapi.usj.cc（国内代理）保持不变	2026-10-03 01:19:02 +08:00
QunLIn	be5abce16a	评论等级改为后端计算（artalk-cf 下发官方 badge） ... 主题原来的九品官阶用 localStorage 累计——只统计当前浏览器 渲染过的评论，换设备/清缓存就失真，别人看到的也不准。 现在后端按全站真实评论数算好，随评论 API 下发 badge_name/badge_color，官方前端原生渲染，跨设备一致。 本文件移除本地注入逻辑，友链/友圈徽章保留。	2026-10-03 01:11:43 +08:00
QunLIn	87cfa01b3d	write-server 切到自建后端：评论 artalk.200181.xyz + RSS api.200181.xyz ... - ARTALK_SERVER: artalk.usj.cc（朋友机器）→ artalk.200181.xyz（自建 CF Workers） - RSS_API_BASE: api.usj.cc（EdgeOne）→ api.200181.xyz（迁到 CF Workers 的 rss-robot-cf） - SCF_PROXY 不变（scfapi.usj.cc 是国内代理，继续复用）	2026-10-02 22:37:54 +08:00
QunLIn	f486a46b6d	修 UpYun 直传：降并发去 --strong、加三轮重试；UpYun 未成功不再刷国内 CDN ... - upx sync 从 -w 10 --delete --strong 改为 -w 3 --delete + 三轮重试（单次 25 分钟）。 本runner 在海外，UpYun v0 接口对并发敏感，-w 10 + --strong 会让一批目录的 mkdir 全部 EOF（2026-10-02 连续两次失败，第二次直接撞 480s 超时）。 upx 0.4.9 只有 -w/--delete/--strong 三个参数，没有 --resume/--checksum， 所以只能靠降并发 + 整体重试。 - 多吉云 CDN 刷新改为仅在 UpYun 成功时执行：EdgeOne 是境外线路， 它成功不代表国内源站已更新，之前会刷出一份"刷新成功但内容没变"的假象。	2026-10-02 20:39:00 +08:00
QunLIn	09f9e96248	评论后端切到 Cloudflare Workers 自建版 ... artalk.usj.cc（朋友机器）→ artalk.200181.xyz 数据已用增量导入同步到 artalk-cf 的 D1。	2026-10-02 19:55:29 +08:00
zqlit	4215e08113	删除一篇文章	2026-10-02 18:04:21 +08:00
zqlit	04d0274d9f	修改文章	2026-10-02 16:44:28 +08:00
Write Server	1ebb167a60	发布: 评论组件被人恶意sql注入，25端口被封，邮件无法发信	2026-10-02 08:15:58 +00:00
zqlit	34c8164d95	merge: 合并 Gitea CI 修复(三态上报) 与内容发布(测试部署) ... - 80ea1ff5 只推过 Gitea，16c5ce33 只推过 GitHub，两条线在 95a8455c 分叉 - 写作后台 origin 的 fetch 只指向 GitHub，看不到 Gitea 上的提交，导致 push Gitea 被拒 - 合并后两边内容一致，此后任何提交都同时推两个远端	2026-10-01 20:53:26 +08:00
Write Server	16c5ce3395	发布: 测试部署	2026-10-01 12:50:18 +00:00
zqlit	80ea1ff5b3	fix(ci): 删除空壳 deploy-upyun job，UpYun 直传改为如实上报三态 ... deploy-upyun 是零上传动作的空壳 job，却无条件打印「UpYun 已同步最新内容」，其输出被 Telegram / 飞书 / 邮件通知当成 UpYun 部署成功的依据；真正的上传步骤标了 continue-on-error，失败也不影响 job 颜色。三层叠加，导致 7/25 起国内线路停更两个多月而通知始终显示成功。 改动：删除 deploy-upyun（finalize / notify-failure 的 needs 同步清理）；Upload to UpYun 在退出时写 GITHUB_OUTPUT，如实上报 success / failure / skipped 三态与真实耗时（不用 steps.outcome，只依赖最通用的 output 传递）；通知与 Step Summary 改为展示三态真实结果，移除「文件已在 Build 阶段同步」这类未经验证的说法。 又拍云直传失败仍不阻断流水线 —— 国内线路由腾讯云广州的 1Panel 计划任务「又拍云同步(国内中转)」每分钟兜底增量推送。	2026-10-01 16:47:05 +08:00
Write Server	95a8455c0e	发布: 删除《GitHub用量又超了》	2026-10-01 06:46:45 +00:00
Write Server	11dda8e66c	发布: 自建了 Gitea，测试一下部署	2026-10-01 05:51:21 +00:00
zqlit	e1f0b49754	fix(ci): 修复提交信息含 ${{ }} 字样导致 pre-check 崩溃 ... 根因：pre-check 的 Validate commit 步骤把 commit message 直接插值进 shell 脚本： COMMIT_MESSAGE="${{ github.event.head_commit.message }}" 多行提交信息会撑破脚本；若正文里出现 ${{ ... }} 之类字样（例如上一次提交 正文中的 ${{ gitea.* }}），bash 会把它当变量展开并报 "bad substitution"， exit 1 → pre-check failure → build 被 skip。 实证（Gitea task 35 日志）： /var/run/act/workflow/commit-check: line 20: perf(ci): 兼容 GitHub Actions... : bad substitution ❌ Failure - Main Validate commit (only for push events) 修复：改用 step 级 env: 传值（COMMIT_AUTHOR / COMMIT_MESSAGE）， commit message 不再进入脚本文本。GitHub Actions 与 Gitea Actions 行为一致，两边都安全，同时消除命令注入面。 本次提交正文刻意保留了 ${{ gitea.* }} 字样，作为该修复的回归验证。	2026-10-01 12:37:22 +08:00
zqlit	92326fff38	perf(ci): 兼容 GitHub Actions 并大幅缩短构建耗时 ... 兼容性（迁移回 GitHub Actions 必需）： - 移除 5 处 ${{ gitea.* }} 专有上下文（Gitea 之外会求值失败）， 改为按 github.server_url 判断的 RUN_URL，GitHub / Gitea 通用 - Telegram / 飞书 / 邮件里的运行详情链接两边都正确 耗时优化： - build: checkout 加 filter=blob:none（partial clone）， 保留完整提交历史供 Hugo 的 :git lastmod 使用， 但不拉历史版本的文件内容（多为图片），省约 200MB 传输 - deploy-edgeone: 移除 checkout（原先约 81 秒），内联原 deploy_edgeone.sh - finalize: 移除 checkout（约 145 秒）与 npm ci（约 66 秒）， 内联零依赖的 refresh_cdn.js（只用 node 内置 crypto 与 fetch） - finalize: setup-node 不再启用 npm 缓存（本 job 已不安装依赖） UpYun 相关按用户要求保持原样不动。	2026-10-01 12:22:41 +08:00
zqlit	ad118b470d	perf(ci): Gitea 环境跳过无效缓存，消除每次约 9 分钟空等 ... 根因：/opt/gitea/runner/config.yaml 中 container.network=gitea_default （job 容器落在 172.20.x），但 runner 容器自身只挂在 bridge 网络 （172.17.0.2），其提供的缓存服务 172.17.0.2:44869 跨 bridge 网段不可达。 实测证据： - runner 容器内 wget http://127.0.0.1:44869/ -> HTTP 404（服务活着） - gitea 容器 wget http://172.17.0.2:44869/ -> download timed out - 构建日志：Setup Node restore 死等 278s（01:07:17 -> 01:11:55 ETIMEDOUT） Post Setup Node save 死等 288s（01:14:54 -> 01:19:42 ETIMEDOUT） Cache Hugo resources restore 亦超时 合计每次构建约 10 分钟纯浪费，且缓存从未真正命中或保存成功过。 改动： - Setup Node 的 cache 改为按 github.server_url 条件启用；Gitea 上 表达式求值为空串，setup-node 自动跳过缓存 - Cache Hugo resources 步骤加 if 条件，Gitea 上不执行（避免 restore+save 双超时） - npm ci 增加 --no-audit --no-fund - step summary 在 Gitea 上如实显示"已跳过"，不再误报"未命中" 无副作用：npm ci 实测 68s 本就是在无缓存状态下跑的（restore 从未成功）， 去掉缓存不会使其变慢；GitHub 侧行为完全不变。	2026-10-01 11:42:43 +08:00
zqlit	6838934fa5	fix(ci): 修复定时构建「无新提交则跳过」逻辑失效 ... 根因：pre-check job 的 outputs.can_deploy 绑定在 steps.repo-check 上， 而该步骤是无条件写 true；真正写 can_deploy=false 的是 steps.cron-check， 它写进自己步骤的 outputs，从未被 job 级 output 采用。 于是 build 的 if: needs.pre-check.outputs.can_deploy == 'true' 恒为真。 证据（run 8, event=schedule）： - 日志 cron-check 已打印「距离上次提交: 9 小时 / 超过 1 小时没有新提交，跳过定时构建」 - 但随后 build 的 if 表达式求值 'steps.repo-check.outputs.can_deploy' 结果为 true，build 照常执行 后果：每天北京 09:00 无条件全量构建（build ~17min + finalize ~12.5min）， 2 核服务器被白占约 32 分钟/天。线上不受影响（build hash 未变， COS/EdgeOne/UpYun 上传与部署均正确 skip）。 改动： - 合并 repo-check 与 cron-check 为单一步骤 decide，统一计算并输出 can_deploy - pre-check.outputs.can_deploy 改指向 steps.decide.outputs.can_deploy - 去掉原 cron-check 的 exit 0（避免步骤提前中断导致 output 丢失）	2026-10-01 11:30:15 +08:00
zqlit	83d87ddeaf	fix(ci): 加固 UpYun 上传步骤，修复 upx 下载挂死 ... 根因：collection.b0.upaiyun.com 实测 2/3 概率整站无响应， 而 curl -sL 无 --max-time，导致步骤永久挂起直到 job 15 分钟超时。 改动： - upx 主源改用 GitHub Releases（实测 0.5s 稳定），原 CDN 降为兜底 - curl 加 --connect-timeout/--max-time/--retry - upx login/put 加 timeout 兜底，sync 加 480s 上限 - 删除无效的 Cache upx 步骤（缓存路径 /tmp 随 job 容器销毁，永远命中不了） - 给 Upload to UpYun 加 timeout-minutes: 10	2026-09-30 23:37:53 +08:00
zqlit	33d54453d7	fix(ci): 用 Python 重写 pre-build 脚本，替换 PowerShell 依赖 ... Gitea 自建 runner 镜像不含 PowerShell，导致 Run Pre-Build Scripts 以 exitcode 127 失败。改用 Python 3（GitHub/Gitea runner 均预装）， 跨平台通用，迁回 GitHub 无需改回。	2026-09-30 22:50:43 +08:00
zqlit	f64d8f30f3	chore: 清理误提交的 .claude/worktrees gitlink ... - 移除 4 个空目录 gitlink（导致 checkout 报 No url found for submodule path） - .gitignore 忽略 .claude/worktrees/	2026-09-30 20:30:08 +08:00
zqlit	8d9eef0f4f	chore: add Gitea Actions support and secrets checklist	2026-09-30 15:20:27 +08:00
Write Server	52aac9f507	发布: GitHub用量又超了	2026-09-08 07:40:10 +00:00
Write Server	651b5e2c45	发布: 流量卡还真得选御三家😂	2026-07-24 02:23:34 +00:00
Write Server	1b96cc4938	发布: 最成功的一次红烧鱼	2026-07-19 03:52:07 +00:00
Write Server	5cf989a5f0	发布: 国企面试，别太当回事儿	2026-07-08 03:20:35 +00:00
GitHub Actions	017b6599bd	chore: auto-optimize images [skip ci]	2026-07-04 10:09:26 +08:00
Write Server	a7e8b80511	发布: 入手了智能手表 OPPO watch x3	2026-07-04 02:07:49 +00:00
Write Server	084719491c	发布: GitHub Action 缓存额度超了，发不出文章😅	2026-06-30 08:40:12 +00:00
Write Server	d527672d1a	发布: 复刻了某红书的西红柿鸡蛋炒牛肉	2026-06-30 08:27:51 +00:00
Write Server	4de59bd22b	发布: GitHub Action 缓存额度超了，发不出文章😅	2026-06-30 04:47:39 +00:00
Vaica	e03d5cb78b	Merge branch 'main' of https://github.com/zqlit/blog	2026-06-30 12:47:29 +08:00
Vaica	673af08c33	Update artalk.html	2026-06-30 12:47:27 +08:00
Write Server	98195aeb39	发布: GitHub Action 缓存额度超了，发不出文章😅	2026-06-30 04:21:19 +00:00
Vaica	08dc480aab	Merge branch 'main' of https://github.com/zqlit/blog	2026-06-30 11:52:46 +08:00
Vaica	94f6f710fc	Update deploy.yml	2026-06-30 11:52:36 +08:00
Write Server	8942769fc6	发布: GitHub Action 缓存额度超了，发不出文章😅	2026-06-30 03:49:12 +00:00
Vaica	8c625f1624	Update deploy.yml	2026-06-30 11:41:34 +08:00
Vaica	38355ce6ac	Merge branch 'main' of https://github.com/zqlit/blog	2026-06-30 11:38:06 +08:00
Vaica	f019c3099a	Update deploy.yml	2026-06-30 11:38:03 +08:00
Write Server	78e8e3c737	发布: GitHub Action 缓存额度超了，发不出文章😅	2026-06-30 03:21:38 +00:00
Write Server	f7e8d9ac1f	发布: GitHub Action 缓存额度超了，发不出文章😅	2026-06-30 03:12:01 +00:00
Vaica	2f735d4628	Update deploy.yml	2026-06-30 10:59:28 +08:00
Vaica	a688134508	Update deploy.yml	2026-06-30 10:45:32 +08:00
Write Server	1bf40d8810	发布: GitHub Action 缓存额度超了，发不出文章😅	2026-06-30 02:37:45 +00:00
Vaica	98b9584b97	Update deploy.yml	2026-06-30 10:31:50 +08:00
Vaica	7b126b58e3	Update deploy.yml	2026-06-30 10:24:51 +08:00
Vaica	8db5e417a8	Update deploy.yml	2026-06-30 10:17:21 +08:00
Vaica	5793280712	Update deploy.yml	2026-06-29 23:08:00 +08:00