利用 GitHub Actions 编译 AUR 包并建立自己的软件源
文章目录
【注】本文最后更新于 June 24, 2020,文中内容可能已经过时。
Arch 用户当然要有自己的软件源!
白嫖真香!
前言
起因是有人在群里发了一篇利用 GitHub Actions 打包 AUR 并建立本地软件源的文章。
我看了看,觉得是好的,因为在本地编译 AUR 包的体验并不咋样:
- 需要下载大量外网的资源,尤其是打 git 包的时候因为 makepkg 不支持 shallow clone 所以不得不将整个 repo 拉下,下载几百兆的东西最后打出一个两三兆的包是常有的事。
- 某些包真的是很难编译,从几十分钟到数小时,感觉自己都变成 Gentoo 用户了……
这篇文章给了我很大的启发,但是文章中的方法并不能满足我的需求:
- 我需要打的包还依赖了其它的 AUR 包,所以仅仅 makepkg 是不够的,我需要一个完整的 AUR Helper。
- 我需要对部分包的 PKGBUILD 进行修改
- 我还想重打某些官方源里的包
- 本地源不够好用,我想直接建立一个个人源。
于是我又自己整了一个项目:https://github.com/Aloxaf/aur-build
效果如下:https://repo.aloxaf.com/
使用方法,将下列文本追加到 /etc/pacman.conf
中,
|
|
然后执行下列命令导入我的 GPG 公钥
|
|
就可以愉快地使用了。
过程中踩的各种坑就不说了反正你们也不想听,直接说用法吧。
准备工作
服务器 x 1
用来建立你的个人源,以及存放加密后的构建脚本。
服务器上只用装好 nginx ,打开 autoindex 并启动即可,你很懒的话直接跑一个 simple-http-server 甚至都可以。因为全部工作都是在 GitHub Actions 上完成的,包括建源。所以理论上放到支持直链的网盘或者云存储上都行。但是我懒,既然有服务器何必闲着。
如果你打算传到云上的话可以使用 uptoc-action,上传目录为 /home/aur-build/.cache/pikaur/pkg
。或者也可以像我开始介绍的那篇文章一样传到 GitHub releases 上。
SSH 密钥 x 1
用于将打好的包部署到服务器上。
由于这个密钥需要上传到 GitHub Actions 上,为了防止可能存在的泄露,建议单独生成一个:执行 ssh-keygen -f ~/.ssh/aur_build
生成密钥,然后将 ~/.ssh/aur_build.pub
中的内容追加到你服务器对应用户的 ~/.ssh/authorized_keys
文件中。
GPG 密钥 x 1
用于签名包,虽然不是必需的但是有这个显得很正规(
出于同样的理由建议生成一个单独的子密钥,没有的话参照这篇文章自己生成一个并上传到公钥服务器上。
GitHub Repo x 1
可以直接 fork 我的 Repo。然后把它 clone 到本地进行修改
配置
塞密钥
全塞到 ./script/data
目录下即可。整个脚本会被加密压缩然后传到服务器上,一般情况下不会泄露。
|
|
建立 ./script/script.conf
这里存放了你的自定义配置,比如你的服务器地址,脚本的加密密码等。我提供了一个 sample 文件,照着改就行了
- 必须要改,不然跑不起来:
GPGKEY
SERVER
SCRIPT
- 建议你改,虽然不改我也不能拿你怎样:
REPO_NAME
PACKAGER
PASSWORD
- 看自己情况决定改不改:
CFLAGS
CXXFLAGS
,其中-march
的值可以通过在自己电脑上执行gcc -march=native -Q --help=target | grep march=
获得
配置 GitHub Actions Secret
在你 REPO 主页点击 Settings -> Secrets -> New secret。
添加两个 Secret
SCRIPT_URL
:你的构建脚本的下载地址PASSWORD
:构建脚本的密码(就是上一节的 PASSWORD)
放入你想要打包的包
在 ./script/packages
下建立对应目录,根据目录内容的不同有三种包:
- 目录为空,则为普通的 AUR 包,构建时会去 AUR 上寻找同名包。
- 目录下有一个 PKGBUILD,则直接用这个 PKGBUILD 打包。
- 目录下有一个 build.zsh,则执行这个 build.zsh 打包
绝大多数情况下都是第一种。
打包上传你的构建脚本
运行 ./script/upload_script.zsh
,构建脚本会被压缩加密并上传到服务器上。然后 GitHub Actions 在执行时会下载这个压缩包并解密再执行里面的脚本。
什么?你问我为什么不直接 push 到 GitHub 上,而要多此一举呢?
其实是为了方便,采用这种方式构建的话,不用每次修改文件都重新 push 一次,只要重新触发 workflow 就行了,尤其是初期测试的时候常常改来改去……这个方法为我省下了大量无意义的 commit。
测试
Push 到 GitHub 上,以触发 GitHub Actions。或者你也可以手动触发,然后就能坐等打包结果了。