Devotd Github
新发现编程智能体

scarletkc/seiso — 按构建行分离发布流水线中的 Rust 缓存

scarletkc/seiso 中按构建平台分离发布工作流 Rust 缓存键的提交,修复了 musl 缓存破坏 manylinux2014 构建的问题。

仓库信息scarletkc/seiso ↗

scarletkc/seiso 中按构建平台分离发布工作流 Rust 缓存键的提交,修复了 musl 缓存破坏 manylinux2014 构建的问题。

GitHub 项目说明: A Markdown convention and linter for project docs written by AI and read by humans and agents

星标
★ 185
复刻
13
语言
Rust
许可证
MIT
最新版本
v0.4.0
查看原始来源 ↗在 GitHub 查看 ↗

scarletkc/seiso 是面向由 AI 编写、由人和智能体阅读的项目文档的 Markdown 规范与 linter。2026 年 10 月 13 日的提交(5bae44f, PR #91)在包发布流水线中按构建目标分离了 Rust 构建缓存。涉及的文件只有发布工作流 .github/workflows/publish.yml 一个,改动为新增 4 行、删除 0 行。

分离的背景是缓存键共享。该工作流用 dtolnay/rust-toolchain@stable 准备 Rust 工具链,用 Swatinem/rust-cache@v2 缓存构建产物。在同一个 runner 镜像中,若多个构建行共享默认缓存键,Alpine 系列的 musl 构建容器保存的条目就会串到面向多个 Linux 发行版的 manylinux2014 构建一侧。结果是,在要求比 manylinux2014 容器中 glibc 更新的 glibc 的宿主构建脚本处构建失败。本次修改在缓存 action 上指定 key: ${{ matrix.platform }},使 gnu 行和 musl 行不再互相恢复对方的构建脚本。在同一工作流中,Rust 测试在 Linux x64 上运行,musl 行的 wheel 则在 Alpine 上验证。

不过,本次提交涉及的范围止于构建缓存隔离。关于 linter 会捕捉哪些规则、Markdown 规范如何定义,本次提交记录中均无记载。表示许可证或 linter 性能的相关数值也未包含在此次记录中。可以把它读作一处虽小但有意义的清理,使发布对特定 runner 镜像状态的敏感度降低。仅凭这次提交记录难以判断 linter 能捕捉到什么,还需要更多依据。