zqlit/blog
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
926 Commits 2 Branches 2 Tags
6bc9eaf8fc13dd48475b87ca37b7128dd6ab6f66
Commit Graph
133 Commits
Author SHA1 Message Date
QunLIn 6bc9eaf8fc 永久跳过海外直传 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 c9c2c32e0d 修 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
zqlit 2293626fea 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
zqlit b9134cdd31 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 671052c4de 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 97b725651f 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 cf27ab8eb5 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 dda5ce94b8 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 34e9e2035a 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 a336bac54c chore: add Gitea Actions support and secrets checklist 2026-09-30 15:20:27 +08:00
Vaica 46af56ece6 Update deploy.yml 2026-06-30 11:52:36 +08:00
Vaica 30bf27fd2f Update deploy.yml 2026-06-30 11:41:34 +08:00
Vaica 3c9beac251 Update deploy.yml 2026-06-30 11:38:03 +08:00
Vaica 3222910f18 Update deploy.yml 2026-06-30 10:59:28 +08:00
Vaica 4087f2a7fc Update deploy.yml 2026-06-30 10:45:32 +08:00
Vaica 2730299414 Update deploy.yml 2026-06-30 10:31:50 +08:00
Vaica cda5d6e00b Update deploy.yml 2026-06-30 10:24:51 +08:00
Vaica fa1bd63645 Update deploy.yml 2026-06-30 10:17:21 +08:00
Vaica 1f2a6f991b Update deploy.yml 2026-06-29 23:08:00 +08:00
Vaica 20954274b7 Update deploy.yml 2026-06-29 22:53:20 +08:00
Vaica d344cb0c2a Update deploy.yml 2026-06-29 22:43:47 +08:00
Vaica ed16734d3c Update deploy.yml 2026-06-29 22:33:32 +08:00
Vaica de608d793f Update deploy.yml 2026-06-29 22:26:59 +08:00
Vaica e012c913fb Update deploy.yml 2026-06-29 22:09:22 +08:00
Vaica 5fc86efb30 Update deploy.yml 2026-06-29 21:58:53 +08:00
Vaica 163d60bde7 Update deploy.yml 2026-06-29 19:21:56 +08:00
Vaica bff1b7c769 Update deploy.yml 2026-06-29 19:16:40 +08:00
Vaica b198a745b9 Update deploy.yml 2026-06-29 19:14:07 +08:00
Vaica 64f7b43703 Update deploy.yml 2026-06-29 19:08:26 +08:00
Vaica 32bacd4e2e Update deploy.yml 2026-06-29 18:50:20 +08:00
Vaica 2dce33fd47 Update deploy.yml 2026-06-29 18:47:25 +08:00
Vaica c9bfe9ecaa Update deploy.yml 2026-06-29 17:54:29 +08:00
Vaica e2cae7c2e6 Update deploy.yml 2026-06-29 17:51:41 +08:00
Vaica 5bc1e50a8d Update deploy.yml 2026-06-29 17:41:50 +08:00
Vaica e9956f2752 Update deploy.yml 2026-06-29 17:35:15 +08:00
Vaica a7d53850e7 Update deploy.yml 2026-06-29 17:26:39 +08:00
Vaica 45045da619 1715 2026-06-29 17:15:56 +08:00
Vaica aaa5fc0855 Update deploy.yml 2026-06-27 19:55:09 +08:00
Vaica 18ce81177f Update cleanup.yml 2026-06-27 19:49:46 +08:00
Vaica 814c6ac475 Update cleanup.yml 2026-06-27 19:44:22 +08:00
Vaica 48c90d63cb Create cleanup.yml 2026-06-27 19:42:53 +08:00
Vaica f1ad78f715 Update deploy.yml 2026-06-27 19:36:51 +08:00
Vaica a946f6cd58 Update deploy.yml 2026-06-25 16:20:57 +08:00
Vaica 10c1120b23 Update deploy.yml 2026-06-25 16:17:35 +08:00
Vaica 228c82fc3f Update deploy.yml 2026-06-25 16:13:23 +08:00
Vaica 4fa4359edc Update deploy.yml 2026-06-25 15:57:45 +08:00
Vaica de0a20784c Update deploy.yml 2026-06-25 15:53:43 +08:00
Vaica f0f7f052d7 Update deploy.yml 2026-06-25 15:38:07 +08:00
Vaica 40f5f3e091 1507 2026-06-25 15:07:25 +08:00
Vaica c7a1c5c02d Update deploy.yml 2026-06-25 14:12:07 +08:00