Add Github actions of the release event.

[tomac4t]

• Github workflows file.
• Debian package script.
• Assets upload script.

[tomac4t]

大概的过程是发布一个新 Release （不能是草稿）会触发 Github actions 事件，在名为 debiab-buster 的 jobs 里会启动一个 debian:buster docker 容器（未来可以加其他容器方便在其他发行版中打包），在容器里面打包，调用 REST API 上传生成的文件（需要 token，使用 ${{ secrets.GITHUB_TOKEN }} 可以在 Github actions 里自动生成一个，不需要手动生成 Personal access tokens，60 分钟后失效）。

ncipollo/release-action@v1 是根据 Tag 事件触发后，自动 create release，再上传 assets。功能很丰富，支持 Changelog。我认为它没法在多个 jobs 里使用，因为 Release 会重复。

官方的 actions/upload-release-asset@v1 则更中规中举，REST API 需要什么就有哪些选项，所以无法像前者一样上传某一目录下所有 assets。

所以就用 python 自己写了上传脚本。

[tomac4t]

One problem when I check build log: the tag (1.0.2-4) created on Web UI didn't fetch, Strange.
是两个 Tags 都在同一个 commit 上造成的，不过现实中一般不会发生。
https://github.com/tomac4t/srain/runs/593968735?check_suite_focus=true#step:5:35

[tomac4t]

I commit the personal token for test by accident. Fortunately, GitHub System immediately revoke my token:

[SilverRainZ]

Q_Q 辛苦托马猫。

[SilverRainZ]

官方的 actions/upload-release-asset@v1 则更中规中举，REST API 需要什么就有哪些选项，所以无法像前者一样上传某一目录下所有 assets。
所以就用 python 自己写了上传脚本。

我理解这是为了以后可能有多个 artifacts 做准备？用多个 upload-release-assert steps 能不能做到呢？

[tomac4t]

我理解这是为了以后可能有多个 artifacts 做准备？用多个 upload-release-assert steps 能不能做到呢？

是的，目前只有 amd64 的包， i386 的包我还没搞明白。upload-release-assert 多个 step 确实可以，但还有一个问题是文件名不是固定的（debian 包生成的文件名取决于 changlog 的版本号和 CPU 架构；他们那边也有类似的 issue，Dynamic Filenames：actions/upload-release-asset#4 ），不过似乎可以通过环境变量获取，就是有些麻烦了。

[SilverRainZ]

明白了，既然他们还不够完善我们就用脚本吧，可以合了？

[tomac4t]

我觉得可以合了，我新开了一个 Private 仓库（怕刷了太多时间线和邮件）测试，目前没有发现问题。

做几个记录：

• Upload a release asset 的 API 必须要求 Content-Type header，这里使用了 python mimetypes 库去判断文件类型。它纯粹是根据文件后缀判断的，如果遇到 README 这种没有后缀的就没有输出了。这一点比不上 file --mime-type [filename] 命令。所以没有的情况我设置成 application/octet-stream，不过未来应该不会遇到这种情况。
• 在 API 中使用 ${{ secrets.GITHUB_TOKEN }} 生成的 token 都被记录为 github-actions[bot] 的操作，而不是其他人。

[tomac4t]

debiab-buster 这个 <job_id> 是我自己取的（也不知道合不合适），未来可以加更多 job，比如用其他 docker 容器打其他发行版的包。

[SilverRainZ]

Get it.