配方管理仓库设计(稿2)

背景

LLAR需要为相关配方提供存储管理，于是我们需要为其设计一个存储的仓库

具体设计

我们选用了GitHub作为我们默认的中心化配方管理仓库

为什么选用GitHub

1. 公开，透明
2. 自带GitHub Actions这类的检查工具，能够帮助我们做自动化检查

其目录结构如下：

{{owner}}/
└── {{repo}}/
    ├──  versions.json
    └── {{repo名称首字母大写}}_llar.gox

_llar.gox, versions.json 为必须入库文件
go.mod, go.sum 可选，当配方需要import时候必须入库，没有也可以

当然，如果存在因为库版本导致配方发生变更，也可以写成这样：

{{owner}}/
└── {{repo}}/
	├── 1.x/
	│   └── {{repo名称首字母大写}}_llar.gox
	└── 2.x/
	    └── {{repo名称首字母大写}}_llar.gox

可以见: https://github.com/goplus/llar/issues/14 配方版本管理

示例： github.com/DaveGamble/cJSON

对应的目录结构将是：

DaveGamble/
└── cJSON/
    └── CJSON_llar.gox

CI系统

产品设计

需求

提交侧(Pull Request)：

• 检查配方是否编写正确
  • 检查是否加载并继承FormulaApp
  • 检查Package Name和Package ID是否已经填写
  • 检查依赖图是否无法自动完成解决或者有构建矩阵的冲突
• 运行配方构建，得到产物后运行测试
  • 超过20种可能性就随机抽样1/10构建矩阵组合，因为如果产生大量构建矩阵组合，将无法全部测试

用户故事

用户可以：

• 使用PR提交到中心化仓库

具体实现

TODO

No implementation files or tests are named. Start by reading issue #14 and the proposed versions.json, *_llar.gox, go.mod, and go.sum layout, then inspect the repository for existing GitHub Actions entry points. Done requires a settled repository design and an implemented CI flow covering the listed validation, dependency, build, test, and matrix requirements.