AUR自动构建支持

[Jerry-Terrasse]

添加了chsrc和chsrc-git两个版本的AUR自动构建workflow，但还有一些问题需要协商解决：

触发条件设定

目前我设定的触发条件如下：

• chsrc: 正式发布时触发（released事件），并且忽略所有非常规版本号的发布（仅接受如v1.2.3）
• chsrc-git: main分支推送时触发

上述设计的合理性需要由作者确认

AUR认证密钥

发布AUR包需要提供包维护者的私钥，使用secrets环境变量传入，参见

我目前想到两个方案：

1. 如果作者乐意进行一些操作，可以在AUR注册帐号，我将你添加为co-maintainer，即可进行自动推送;
2. 也可以由我维护一个仓库专用于自动推送，并在主仓库中配置webhook来触发;

或许也有更好的方案？

[ccmywish]

Good job

感谢你持续无私地贡献时间与精力。❤️

看了你写的 workflow，非常漂亮简洁。👍

触发时机

chsrc 除了大的版本 release 外，还会经常推送到 main 分支以让用户尽快使用新功能和bug修复

所以支持这两个触发时机是符合 chsrc 一直以来的发布模型的。

能否给 bin 这个 action 额外加一个 tag 的触发？ Homebrew formula 的更新目前就是不仅仅考虑 release，也会考虑 tag。

版本

如果 AUR 没有特殊要求，能否往后再支持一个小数点？比如支持现在的 v0.1.8.1，最后面的这个 1 也是会打 tag 推送到GitHub的。

AUR认证秘钥

我的账户：https://aur.archlinux.org/account/ccmywish

可以把我添加为co-maintainer，我来辅助处理。因为尽量还是把内容集中到一个仓库比较好进行后续维护。

许可证问题

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chsrc#n23

bin 这个的 source，这里应该给两个许可证文件。如果AUR要求只能给一个，也应该使用的是 GPL 的许可证文件。https://github.com/RubyMetric/chsrc/blob/main/LICENSE-GPL.txt

[ccmywish]

看看是否需要按上述评论调整一下

[Jerry-Terrasse]

触发时机

可以添加tag触发，但我目前没有理解为什么要区别于release使用tag来进行一些发布？请让我理解你的设计意图。

版本

好的。
但我注意到v0.1.8.1没有发布二进制产物，这使得无法打包bin版本，这是否是有意为之？

AUR认证密钥

已添加。

许可证问题

目前声明的均为MIT, GPL-3.0-or-later协议，可以查看AUR - chsrc中的Licenses条目。Sources仅有MIT协议是因为MIT协议要求软件包中包含协议原文，而GPL协议无此要求，仅需声明即可，参见

[ccmywish]

@Jerry-Terrasse

现有的发布模式

1. 我把符合semver的版本，形如x.y.z，称为 Standard Release，可暂时简称为stdr
2. 我把带有第四个数字的版本，形如x.y.z.P，称为 Prerelease，可暂时简称为prer

GitHub Relases 里只会发布 stdr，你可能想问的问题是，为什么 prer 不发布到 stdr 中。

简单来说，我想让所有用户都访问到 prer。实际上，所有通过README中链接手动下载的用户，都会访问到 prer。以下是为什么 prer 不能作为 stdr 的原因：

原因1：这些功能或 Bug fix 足够小或者少，不足以发布一个真正的版本（符合 semver 的版本）
原因2：我们总不能每做点工作，就发布一个版本
原因3：其实stdr才是真正意义的stable版本，为了确认它真的功能有效，没有引入其他bug，需要我自己以及某些真实用户真实测试过。只有确认了后，才能发布真正的stable版

所以说，prer的存在是为了更快的反馈用户的响应，这个反馈可能是一次没有经过充分思考但是却能解决用户实际问题的 quick fix，所以它不足以成为 stdr

[ccmywish]

v0.1.8.1 的二进制产物其实在 （两个链接内容一样）

1. https://github.com/RubyMetric/chsrc/releases/tag/pre
2. https://gitee.com/RubyMetric/chsrc/releases/tag/pre

能不能直接让 bin 去始终下载这里的文件？

[Jerry-Terrasse]

关于发布模式

赞同Prerelease的存在，但关于AUR包的发布节奏，我有如下考量：

按照AUR社区的惯例，我把chsrc包设定为稳定版，chsrc-git设定为源码编译的最新版。我认为chsrc包可以认为对应于Standard Release，而chsrc-git则适用于想要最新功能的用户，对应于Prerelease（但更激进，直接与main分支同步）。

按照这种逻辑，我认为Prerelease不应当发布到chsrc包中，这会导致想要稳定版的用户接受到过于频繁的更新。

我觉得一个比较合理的折衷或许是：

将Standard Release发布为chsrc包，然后将chsrc-git包的触发条件改为所有tag，从而包括两种类型的Release，而不是随main分支发布，这样也能使得日后更新main分支不必过于谨慎。

另外，如果你仍然认为有必要保留stdr prer main三种发布节奏，我们也可以新增一个chsrc-pre包专用于包含Prerelease的版本。

关于Prerelease的二进制产物

始终从pre处下载在技术上是可行的，但是会比较奇怪，这样做会使得打包原材料和版本号解耦合，有可能在未来造成不必要的麻烦（例如发布新prer时必须人为地遵循“先更新产物，再发布”的顺序，否则AUR那边就会获取到实质上旧的二进制）。

当然，如果如前文所述将Prerelease发布到chsrc-git包，则完全无需考虑这个问题，因为chsrc-git包是从main分支编译构建的，不需要二进制产物。

[ccmywish]

既然有惯例，可以直接按照惯例来，

1. 一个正式发布的版本 chsrc
2. 一个直接从main 获取的 chsrc-git

这两个一个足够稳定，一个足够“激进”。这么一讨论，我其实觉得再搞一个 chsrc-pre 的意义不是很大，靠 chsrc-git 就可以了。

咱们就按当前这样，无需再修改了。

[ccmywish]

刚触发了一次推送。这样的话，似乎每次往main分支推，都会重新打包，这样会不会太频繁？

因为你刚才提到 ：

“想要稳定版的用户接受到过于频繁的更新”

用户会频繁被打扰到吗？比如有消息通知之类的？

[Jerry-Terrasse]

这是正常的，我认为-git版本这样做是合理的，且一般不会有过于heavy的通知。

[ccmywish]

那就没问题了。

感谢你对此所花费的大量时间和耐心，跟你合作收获良多 ❤️🤝

Happy changing source~

[Jerry-Terrasse]

合作愉快👍👍👍

随后我将会对已有的AUR包做更新，支持更多架构，以及引入make test（参见)。

顺便问一下，目前make test的时间似乎有点长（我这里是22s），是否有可能提供更轻量的用于简单验证产物正确性的选项？

另外，日后如果有AUR包相关的其他需求请随时@我。

[ccmywish]

check 这个步骤是会发生在用户安装时吗？如果是这样，我可以额外提供一个 make check，方便快速检查。

因为我刚好计划重新调整 make test，可能等那会儿再一并引入 make check.

像Homebrew，基本就只随意的测了一下。而Scoop根本就不测。所以我觉得目前可以暂时就先不测，无伤大雅。等到上述完成时，我再 @ 你 🤝
https://github.com/Homebrew/homebrew-core/blob/master/Formula/c/chsrc.rb#L25-L26

[Jerry-Terrasse]

check 这个步骤是会发生在用户安装时吗？

是的。

那么就等完成时我再添加吧。