Repository navigation
deb 包构建 与 其自动构建和发布 #202
Description
我愿意维护deb软件包的ci自动打包与发布,但是deb软件包发布方式想要与大家一起讨论
- 在github release中提供deb软件包
- 利用github page 提供 apt 仓库(可以在提供的deb包中自动添加apt仓库)
这是我目前构思的发布方式,欢迎大家指正
{{ message }}
我愿意维护deb软件包的ci自动打包与发布,但是deb软件包发布方式想要与大家一起讨论
Activity
ccmywish commentedon Jun 10, 2025
@sanchuanhehe
非常高兴看到你愿意参与维护
.deb包的 CI 自动打包与发布工作！这是chsrc项目分发长时间缺失的一部分，你的加入对我们帮助非常大 🙌关于第一点
这也是大家所期望的，直接在 GitHub Releases 中发布，你在实践中遇到什么问题可以随时留言。
关于第二点
我们利用 GitHub Pages 托管的网站 https://chsrc.run 放在本仓库的
gh-site分支：https://github.com/RubyMetric/chsrc/tree/gh-site/docsAPT 仓库是否会放一些元数据和
.deb文件？如果要放比较大的或者经常变动的二进制文件，我们可另外开一个新仓库来托管。sanchuanhehe commentedon Jun 11, 2025
APT 仓库会放一些元数据和 .deb 文件,但是现在的可执行文件不大,也没什么依赖,deb包在100k以内
sanchuanhehe commentedon Jun 11, 2025
@ccmywish
请问 https://github.com/RubyMetric/chsrc/tree/gh-site/docs/ 被映射到了 https://chsrc.run/ ,是这样的吗
sanchuanhehe commentedon Jun 11, 2025
https://chsrc.run/是否有镜像或cdn加速,国内用户使用是否稳定
@ccmywish
ccmywish commentedon Jun 11, 2025
是的
没有镜像或CDN。只购买了 https://chsrc.run 这个域名，用的就是 GitHub Pages 服务。
有人报告过 https://chsrc.run 无法访问，所以稳定性说不准。
README 里写了如果访问不了 chsrc.run，就替换为 Gitee 上的等价地址。如果访问不稳定，可以开一个 Gitee 仓库来存储看看是否可行。
sanchuanhehe commentedon Jun 11, 2025
能否之后配置下镜像或CDN(cdn就够了,甚至很多云服务商的cdn都是免费的),毕竟换源工具的源应该先保证稳定
ccmywish commentedon Jun 11, 2025
@sanchuanhehe
换成 Cloudflare 的 Free plan 了，不知道作用大不大。你有更好的方案吗？
ccmywish commentedon Jun 11, 2025
研究了下，估计效果不太好。用国内的 CDN 应该还要备案，似乎有点麻烦。
APT 仓库有必要存在吗？单纯只是为了 apt install 更新方便吗？
我觉得只需要单纯分发 .deb 包到 GitHub Releases 中即可，没有那么多麻烦的维护工作。你觉得呢？
sanchuanhehe commentedon Jun 12, 2025
我以前用cloudfare 的 free plan感觉还不错
12 remaining items
[-]Deb 软件包自动构建与发布[/-][+]DEB 软件包自动构建与发布[/+]ccmywish commentedon Jun 15, 2025
通过 push 到
gh-build分支触发构建，已运行成功：https://github.com/RubyMetric/chsrc/actions/runs/15660509357/job/44117489706
发布到了
pre这个 release 中：测试安装：
man 手册也可以正常打开。
现在略有问题的是 version，为了测试我先随意设置了个
9.9.9sanchuanhehe commentedon Jun 15, 2025
收到,我来研究下apt仓库的搭建
Deprecate `actions/upload-release-asset`
ccmywish commentedon Jun 16, 2025
@sanchuanhehe
我这两天基于你的工作，改动了许多细节，但是依旧是以你的工作成果为核心。和你沟通一下，方便快速明白现在的代码情况，以及为什么我改动，以及你之后修改代码对模糊不清的问题可以有一定的依据。
所有地方统一称呼为标准的小写
deb，之前我全部改为DEB了，是我想当然了，现在全面改回来将
debian挪至pkg/deb，我看许多项目都在根目录放了debian，这应该是一种惯例，但是我觉得不妥，每增加一个新打包系统都要放在根目录的话，有些凌乱，而且构建的时候，生成的deb包会在源代码上一层目录，刚好在编辑器的视线之外，看不到拆分两个 Makefile
make build-deb和make clean-deb（调用下面的 Makefile），动词在前，和其他 target 一样make deb-buildmake deb-clean现在我们开发的时候想要构建，一般从根目录就可以了，GitHub Actions 中也是直接调用的
make build-deb来构建，deb 包将生成在pkg/下（似乎debuild总是生成到CWD的上层目录）。补充文档、注释、文件头部的作者信息，增加可理解性
Actions workflow 的 step 能用中文名就用中文名，在 GitHub UI 里看的更清楚。能给中文注释就给，因为YAML文件，又混入shell脚本，可读性有点差，用中文显性区分，增加可维护性
Actions 里的上传到 release 的 action 已经被 deprecate 了，换成了现在广泛使用的一个第三方 action。其他 workflow 文件也在使用这个替换后的 action
现在 deb 包将和其他二进制一样，都在我推送到
gh-build分支的时候构建，并上传到prerelease，名字固定为chsrc_latest-1_amd64.，这样使得 URL 对用户来说一直保持不变：https://github.com/RubyMetric/chsrc/releases/download/pre/chsrc_latest-1_amd64.deb 。在发布 release 的时候，也会触发构建，其文件名中带有版本号，是从源代码
chsrc-main.c的版本信息中直接提取的，而非上面的latest-1。但是现在还没测试，等v0.2.2发布的时候测一下。README中已更新可以使用该方法安装。
[-]DEB 软件包自动构建与发布[/-][+]deb 包构建 与 其自动构建和发布[/+]sanchuanhehe commentedon Jun 16, 2025
感谢您的提醒,这对于我非常有帮助
sanchuanhehe commentedon Jun 16, 2025
但是理顺这个目录调用关系有点晕
sanchuanhehe commentedon Jun 16, 2025
能讲一讲注释格式标准吗,我遵循下
ccmywish commentedon Jun 17, 2025
就是根目录 ./Makefile 调用 ./pkg/deb/Makefile
ccmywish commentedon Jun 17, 2025
你直接看各个文件的头部就行了