add_urls 添加 github 项目时，优先使用具有稳定 hash 的地址

[inkydragon]

你在什么场景下需要该功能？

问题：目前 xmake-repo 中，add_urls 时，如果使用从 github.com 上获取到源码包，hash 不一定是稳定的。

上一次中断在 2017.
最近的中断 2023-01-31，下一次最快在一年之后：

• Checksum mismatches on .tar.gz files · Discussion #45830 · community
• Git archive checksums may change | Hacker News

Github 最近明确了下载 tarball 时 hash 稳定性的问题。

If you rely on stable archives for security (ensuring you don’t accidentally trigger a tarbomb, for example), we recommend you switch to release assets instead of using source downloads. On the Releases page, these are the assets which were uploaded to GitHub and appear with their file size. Files can be added to a release manually in the web or with something like this (third-party) GitHub Action. You can later use the Release Assets REST API to retrieve them. If relying on release assets isn’t possible, we urge you to consider designs that can accommodate (infrequent) future hash changes.

—— https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/

简单来说

• 只有手动上传+发布release的文件（压缩包）的 hash 才是稳定的
• release 里最后两个自动生成的压缩包的hash，在一定时间内保持稳定（今年的稳定期是 2023-02-21+1年）
• 其他方式（URL/API）生成的压缩包不提供保证
  • https://github.com/${org}/${repo}/archive/refs/tags/${TAG}.tar.gz

描述可能的解决方案

• 在文档里提及压缩包的稳定性问题
• 合并 pr 时，建议优先使用具有稳定 hash 的下载地址
• 对于现存的构建脚本，如果有稳定的地址，则更新

作为下游构建工具其实没有太多好的办法。
只能尽量避免使用不稳定的下载地址。

描述你认为的候选方案

• 在 github 更新 hash 算法时，更新整个 repo 受影响的的 hash
  最高的频率大概也就1年一次，写个脚本定期跑一下也可以

其他信息

• Should rulesets distribute a pre-built artifact rather than rely on GitHub source/release archive bazel-contrib/SIG-rules-authors#11 (comment)
  最近的一次 hash 更改，集中讨论
• GitHub archive hash stability · Discussion #46034 · community
  这里有很多构建系统的维护者的回复。是 github 那篇 blog 的前置讨论
• chore: publish release artifact bazel-contrib/rules-template#44
  bazel 把他们的模板也改为使用稳定的源码包了

[waruqi]

这好像也没啥办法，目前这边精力有限，也不可能挨个维护，脚本更新量太大，很多还是需要挨个 review 的。

只能等遇到问题了，根据 issues 反馈，针对性修复一些热点包。

[inkydragon]

脚本更新量太大，很多还是需要挨个 review 的。

恩，脚本更新只能是应急的时候用一用，review 也是一大个问题。
所以我没有把这个作为主要的建议。

这个问题也不只是影响 xmake，只要依赖 github 分发的构建工具都会多少有些影响。
其他信息#2 的那个连接，里面就包含：vcpkg、Conan、Bazel、Buildroot、EasyBuild... 等一众构建工具的抱怨。
大家其实都没啥好的办法。

我逛了几圈，得出的建议如正文所述

1. 在 xmake 和 xmake-repo 的文档、readme 里提到这一点。
   （如果可行，我就尝试提交一个 pr）
   很多情况下，其实并没得选，有些包甚至不发 release。不过至少得让用户知道有这个风险。

2. 然后就是如果有新包入库，可以在合并的时候考虑这一点。
   能用有稳定 hash 的 release 自然是最好的，如果有其他的分发渠道也可以考虑（官网之类的）。
   实在没有，那也没关系。

3. 对于 "对于现存的构建脚本，如果有稳定的地址，则更新"
   我本来想举几个例子，随便挑了几个包，就没找到除 xmake 以外会手动 release 源码包的项目。。。
   现在看来这一条也许可行性不太高。更多的时间会花在寻找可以改进的包上

[waruqi]

在 xmake 和 xmake-repo 的文档、readme 里提到这一点。

其实提了，也不会有多少人看的，就算看了，也解决不了问题

到时候遇到问题，通常都有 shasum 不一致的报错，用户也能猜个大概，就算不知道是 github 的问题，至少也能提 pr 去修复 shasum

然后就是如果有新包入库，可以在合并的时候考虑这一点。

原本就是优先走的 releases 的。

对于 "对于现存的构建脚本，如果有稳定的地址，则更新"

xmake的包，也不是所有都完全依赖 github tar url ，很多包还是有其他镜像 url 的。而且就算所有 tar url 都失效了。。

很多还配置了 git url，xmake 对 tar url 下载失败的时候，会自动回退到 git url 去 clone/checkout 下载。。所以影响也还好