zhengchen.tao/ezbookkeeping
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
3,179 Commits 2 Branches 20 Tags
ce345f79abb46023fd87e27990786fad74f326e3
Commit Graph

26 Commits

Author SHA1 Message Date
zhengchen.tao ce345f79ab build-image.yml 注释微调（触发 concurrency cancel-in-progress 测试） 
把 "重新打包旧 commit / 用自定义 tag / 等" 里多余的斜杠改成顿号，
顺便利用这次 push 验证上一条 d92e4fe3 的 in-progress run 是否被取消。
 2026-05-04 00:40:43 +08:00
zhengchen.tao 6baf668696 build/deploy 合并为单 workflow 双 job，删除 deploy.yml 
原 workflow_run 链触发会在 Actions 列表产生两条独立 run，UX 割裂。
合并后单 run + dependency graph 显式串联 build → deploy。

代价：失去"不 rebuild 只 redeploy"的 UI 单点触发，临时只想
重启容器需直接 ssh NAS 跑 docker compose up -d。

paths-ignore 同步移除已不存在的 deploy.yml 项。
 2026-05-04 00:37:44 +08:00
zhengchen.tao 9ef0e62b05 fix(deploy): 加 docker login 步骤，否则 pull 私有 registry 401 
build-image 跑过 docker login，但 deploy 是独立 workflow 容器，
凭据不继承。需要在 deploy 这边也登一次同一个 PACKAGES_TOKEN。

deploy.yml 在 paths-ignore 里，这次提交不会触发 build。但会触发
deploy 自己（不在 paths-ignore，且 workflow_dispatch 仍可手动）。
要测的话手动 dispatch Deploy Docker Image 即可。
 2026-05-02 23:39:15 +08:00
zhengchen.tao 7df2d49c56 build-image paths-ignore 加 deploy.yml / sync-upstream.yml 
改 deploy.yml 或 sync-upstream.yml 都不影响镜像内容（前者是部署
脚本、后者是 main reset 脚本），原本会触发整套 ~10 min 的 build
是浪费。把它俩加进 paths-ignore 跳过。

build-image.yml 自己保留触发（不在 ignore 里），这样改 workflow
能 self-test 验证改动有效。
 2026-05-02 21:23:18 +08:00
zhengchen.tao 65d52571de build/deploy workflow 加 concurrency cancel-in-progress 
并发组 = workflow name + ref。同分支连续 push 时：
- 新 run 入组发现已有 in-progress run → 立即取消旧的，新的开跑
- 最终只构建 + 部署最新代码，省 CI 时间
- 不同分支的 build/deploy 互不干扰（虽然当前只 custom 用）
- build 与 deploy 是两个独立 workflow name，互不影响（build 跑时
  deploy 不会被取消，反之亦然）

CLAUDE.md 同步加"并发取消策略"段说明该行为。
 2026-05-02 21:18:39 +08:00
zhengchen.tao 4bdd2c7195 deploy.yml 移除 CUSTOM_DEPLOY_SCRIPTS 变量，部署脚本内联 
原 vars.CUSTOM_DEPLOY_SCRIPTS 来自 deploy.yml 上游模板设计，本意是
"通用 hook，让一份 deploy.yml 复用到不同项目"。本仓库只有一个项目
一种部署场景，这层抽象纯属累赘：
- 改部署逻辑得去 Gitea UI 点 Variables，没法 PR review
- git log 看不到部署逻辑改动
- 脚本到底跑啥得对照 yml + Variable 两处

直接把 docker compose pull/up 内联进 deploy.yml，单一事实源在 git。

支持私有 / 公开两种 nas-infra：
- secrets.NAS_INFRA_TOKEN 设了 → 用 token clone（私有适用）
- 没设 → 裸 URL clone（公开适用）

CLAUDE.md 同步更新 deploy.yml 的描述。
 2026-05-02 21:10:35 +08:00
zhengchen.tao 9da91ad54f deploy.yml 改自动触发：build 成功后 workflow_run 链式触发 
- on.workflow_run: 监听 Build Docker Image 完成事件，分支限 custom
- if 条件：仅在 build 成功时跑 deploy（失败时跳过，避免部署半成品）
- workflow_dispatch 保留作为手动备选（重新部署当前镜像 / 应急脚本）
- 脚本生成改 > 覆盖（原 >> 会累积历史脚本）+ 加 set -e 失败即停
- 加 Deploy summary 步骤把触发链路信息写入 GITHUB_STEP_SUMMARY
  方便从 UI 看到本次 deploy 跟在哪次 build 后面

CLAUDE.md 同步更新 workflow 清单 + 流程图：现在 push → build →
deploy 全自动 CD，仅需在 repo Variables 里配 CUSTOM_DEPLOY_SCRIPTS
脚本内容才能产生实际部署效果。
 2026-05-02 21:07:09 +08:00
zhengchen.tao 55c175acca ci: 注释 paths-ignore 对 empty commit 的 vacuously-skip 行为 
empirical discovery：c6bb0c85 那个 --allow-empty commit 推送后没有
触发 build。证实 Gitea Actions（同 GitHub Actions）对 paths-ignore
+ empty commit 的处理是"vacuously matches ignore list, skip"。

把这个 quirk 直接注释在 workflow 文件里，后续自己或 Claude 看到
build 没触发时不用再怀疑 trigger 配置错了，知道是 empty commit 的
正常行为。
 2026-05-02 20:49:17 +08:00
zhengchen.tao 32a49be913 build-image workflow 改自动触发 + 保留手动备选 
- on.push.branches: [custom] —— 推送 custom 自动跑
- on.push.paths-ignore：屏蔽 *.md / .gitignore / LICENSE / screenshot/**
  避免 doc-only 改动浪费 ~10 min 构建
- on.workflow_dispatch 保留作为应急通道（重打旧 commit / 自定义 tag）
- checkout ref 兼容两种触发：${{ inputs.branch || github.ref_name }}
  - workflow_dispatch：用用户填的 branch（默认 custom）
  - push：fallback 到 github.ref_name（即触发分支，永远是 custom）
- Build summary 加"触发方式"行，便于区分本次是自动还是手动

预期：本提交本身就会触发自动构建（改了 .gitea/workflows/build-image.yml
不在 paths-ignore 内），相当于 self-test。
 2026-05-02 20:41:22 +08:00
zhengchen.tao ebcc03d3d0 docs: ci 分支已删除，更新 CLAUDE.md 与 build summary 措辞 
ci 分支于 2026-05-02 删除（默认分支已切到 custom，workflow 文件已
迁回 custom）。更新各处反映"两分支模型 main + custom"的最终状态：

- CLAUDE.md "三个分支" → "两个分支"，ci 段改写为"已退役 + 历史
  说明"，给后续 Claude 解释 git log 里 555ecc1a 这条迁移提交
- 同步历史里 2026-05-02(后续) 那条加上"随后删掉 ci 分支"的事实
- build-image.yml 的 Build summary 步骤移除"UI 顶部 commit 是 ci"
  的警示注释（workflow 已在 custom，runs 列表 commit 直接就是
  代码 commit，不再需要这条解释）
 2026-05-02 20:34:38 +08:00
zhengchen.tao dfbc2b1440 ci: workflow 文件迁到 custom 分支 
之前 workflow 在 ci 分支，导致每次 dispatch 后 Gitea Actions 列表
显示的 commit 都是 ci 分支的 workflow 文件 commit，不是被实际构建
的 custom 代码 commit，UX 上误导性强。

挪到 custom 后：
- runs 列表的 commit 字段直接显示真实代码 commit
- workflow_dispatch UI 自动从默认分支（待手动切到 custom）发现
  workflow
- rebase 上游时 workflow 文件随 custom 一起平移，无额外操作

同步移除上游残留的 docker-release.yml / docker-snapshot.yml：
- 触发依赖 secrets.DOCKER_REPO（未配），sync-upstream 推 main
  /tags 时空跑失败
- ci 上已禁用，但文件留着是噪声，本次清掉

ci 分支 .gitea/workflows/ 暂保留作过渡，待用户在 Gitea UI 把
默认分支切到 custom + 验证 build 跑通后，再单独 cleanup ci。
 2026-05-02 18:35:53 +08:00
MaysWind d936b64cf9 build script supports setting the build time and date through environment variables 2025-10-17 21:57:33 +08:00
MaysWind 23a85d6162 update action version 2025-10-13 00:04:05 +08:00
MaysWind 5400a1424c do not check third party response when run tests in ci pipeline 2025-07-02 22:17:25 +08:00
MaysWind 6787d0591e support skip specified tests when build release 2025-03-10 22:02:08 +08:00
MaysWind 319f97bf9e use QEMU 8.1.5 2025-01-31 23:00:08 +08:00
MaysWind da31a67c52 upgrade actions 2025-01-31 22:33:50 +08:00
MaysWind dd155a0f63 add gitea deploy action 2024-12-22 17:21:53 +08:00
MaysWind 10e4bcc723 skip specified tests when build snapshot image 2024-12-08 22:20:16 +08:00
MaysWind 185758b638 use current platform to build frontend assets 2024-03-25 00:30:56 +08:00
MaysWind 2e680b04c9 supports building for different platforms for gitea actions 2023-09-04 23:33:52 +08:00
MaysWind 6b30a0aebc supports building multiple image by gitea actions 2023-09-02 19:33:48 +08:00
MaysWind 439608cf27 remove unused configuration 2023-07-14 22:46:00 +08:00
MaysWind 53a31cd4c4 use variables to replace secrets 2023-07-03 23:02:17 +08:00
MaysWind aff876aa05 only trigger gitea docker-snapshot workflow when push to main branch 2023-05-28 17:59:25 +08:00
MaysWind 0a011b6075 add gitea actions 2023-05-20 23:49:00 +08:00