参考 on SOW

sow.yml 配置参考

Mon, 01 Jan 0001 00:00:00 +0000

sow.yml 是 Managed 托管工作区(Workspace)唯一的配置文件。它位于工作区根目录, 声明存在哪些仓库(Repository)与 Dist,并保存每次构建都要执行的成员策略与签名设置。 Plain 平面模式(sow create)完全不读它。

包引用

Mon, 01 Jan 0001 00:00:00 +0000

sow rm、sow show、sow where 都接受一个 PACKAGE 参数。本页定义你能在那里写什么。三条命令共用同一套文法,只有对歧义名称的处理不同。

这里的内容与 sow add 无关 —— add 接受的是文件系统路径,不是包引用。

仓库布局

Mon, 01 Jan 0001 00:00:00 +0000

SOW 的磁盘布局是固定的。没有 path: 配置项,没有模板,也没有办法把仓库挪到别处 —— 每一条路径都由工作区根目录、一个已校验的名称和固定的相对片段推导而来。本页给出完整地图,让你清楚哪些该发布、哪些该复制、哪些必须留在本地。

退出码

Mon, 01 Jan 0001 00:00:00 +0000

每条 sow 命令都以七个退出码之一结束。它们是稳定的、对所有命令一致, 并且就是设计来给脚本做分支判断的 —— 区分"这件事失败了"和"这件事被正确地拒绝了", 正是设置多个非零码的全部意义。

JSON 输出

Mon, 01 Jan 0001 00:00:00 +0000

所有产出数据的命令都接受 --json。输出是 stdout 上的一行版本化信封 —— 不管是哪条命令产生的,都能直接管道给 jq。

sow status --json

{"schema":"sow.cli/v1","command":"status","ok":true,"repository":"pigsty","operation":null,
 "result":{"repository":"pigsty","status":"clean","ready_to_copy":true,"desired_revision":4,
 "built_generation":4,"dirty_dists":[],"dirty_reasons":[],"pending":{"count":0,"bytes":0},
 "recent_operation":{"id":"8632724976452398569","kind":"add","state":"done",
 "created_at":"2026-08-04T04:07:17.665377Z","updated_at":"2026-08-04T04:07:18.293848Z"},
 "repository_locked":false},"errors":[]}

(此处为便于阅读做了折行,实际输出是一行。)

兼容性

Mon, 01 Jan 0001 00:00:00 +0000

SOW 输出的是标准 rpm-md 与 Debian archive 元数据,所以问题不在于客户端"能不能"读, 而在于哪些客户端确实被验证过。本页给出实测矩阵、二进制支持的平台, 以及少数几条忽略了就会出问题的约束。