简单自用的自动化 AUR

起因

我的日用系统从 Windows 切到 Arch Linux 已经小有一段时间了，过程中难免会遇到部分软件包无法满足我的需求以及部分在 AUR 的包不能及时跟上上游版本，所以打算托管一个 PKGBUILD 仓库，然后使用 GitHub Action 来完成日常的检查版本、构建相关包、推送到源仓库。

在此之前需要明确我的需求：

仓库中主要包含与构建产物小、上游更新较频繁的包
仓库中主要为满足我自己需求的、AUR 中可能不存在的 PKGBUILD

搜索了一下发现大家都主要是自动化构建 AUR 中存在的包，流程中很难加入自己的 PKGBUILD；而且有的构建流程写得很死，我也没有相关经验所以看着很头疼。后来翻到了这位开发者的两个仓库：zaggash/archlinux-aur 和 zaggash/gh-workflows ，看过他的工作流后不禁称赞，不仅主打一个可复用性而且简单修改就能满足我的需求，算是我工作流的启蒙了。

因此我打算基于这两个仓库的工作流框架来自建 AUR 仓库。

搓轮子

目前的架构为：

支持直接导入 AUR 的 PKGBUILD（submodule 形式引入）以及自定义 PKGBUILD（需要自己打标签）
Renovate 负责监控部分包版本以及修改更新 PKGBUILD 中的版本信息
nvchecker 用于补充监控部分包版本
GitHub Action 作为自动化主体
包存储选择了 GitHub Releases 与 CloudFlare R2
（可选）r2-dir-list 作为简单的仓库前端

Renovate

版本标签

Renovate 的官方文档中其实就有一篇管理 AUR 的文章：Maintaining AUR packages with Renovate ，但主要解决的是 AUR 维护者的日常版本更新问题，不过也提供了很好的例子来展现 Renavate 如何获取和更新版本。

在 Renovate 的配置文件中需要配置一个自定义的包管理器（因为没有 AUR 相关的预设包管理器）。绝大部分代码都是来自文档，我只修改 matchStrings 和添加了 autoReplaceStringTemplate，都是为了一个目的：如果你 pkgrel 不为 1 时，更新 pkgver 后同时更新 pkgrel 为 1。

"customManagers": [
  {
    "customType": "regex",
    "fileMatch": [
      "(^|/)PKGBUILD$"
    ],
    "matchStrings": [
      "pkgver=(?<currentValue>.*) # renovate: datasource=(?<datasource>.*) depName=(?<depName>.*)\\npkgrel=(?<pkgrel>.*)"
    ],
    "extractVersionTemplate": "^v?(?<version>.*)$",
    "autoReplaceStringTemplate": "pkgver={{{newValue}}} # renovate: datasource={{{datasource}}} depName={{{depName}}}\npkgrel=1"
  }
]

然后你只需要在原有的 PKGBUILD 中的 pkgver 行添加注释作为标记，并且下一行为 pkgrel：

pkgver=1.2.2 # renovate: datasource=github-tags depName=LiteLoaderQQNT/LiteLoaderQQNT
pkgrel=4

其中的 datasource 就是获取版本信息的来源，你可以使用 Renovate 预设的各种值以及自己编写 custom 源（我还是非常推荐 all in custom 源然后交给 nvchecker 来获取版本信息，nvchecker 节会解释）。而 depName 可以理解为 “包” 的名字。你可以这样理解：在 github-tags 中有 a、b、c 不同的仓库，而你需要的只是 b 这个仓库的相关信息，所以你需要填写 depName=b。

自定义版本源

只有自定义包管理器还不行，你需要为 Renovate 的 datasource 提供版本信息的来源，所以下面来写一个自定义源，在动手前推荐看 Renovate 开发者的这篇博客，相比官方文档其可以说得上是手把手教学。

上文我有提到建议 all in nvchecker，这里我稍微解释一下。如果你的各种 PKGBUILD 中包的上游并不统一（比如都来自 a、b、c 等平台而且都没有预设）并且你需要通过比较 hack 的方式来获取版本号（比如闭源软件），那么根据 Renovate 文档中提到的方式写一个自定义版本源，你就需要为不同的平台写一个不同的源而且那些 hack 的方式都无法实现。因此我选择了 nvchecker 来完成版本号的获取。

datasource 对接 nvcheher 只需要这样：

"customDatasources": {
  "nvchecker": {
    "defaultRegistryUrlTemplate": "https://raw.githubusercontent.com/CAB233/myAUR/main/.github/new_ver.json",
    "transformTemplates": [
      "{ \"releases\": [{ \"version\": data.'{{packageName}}'.version }] }"
    ]
  }
}

defaultRegistryUrlTemplate 用于指向 nvchecker 生成的结果，可以是本地文件也可以是远程文件。transformTemplates 用于将 nvchecker 的结果转换为 Renovate 能够识别的信息（如果你使用原始的 nvchecker，则转换规则不需要改动）。

包规则

在这里你可以对监控的一堆包进行针对性设置，例如你可以指定 a 包仅每个月检查一次更新、b 包需要你的审阅后才能更新。更多设置你可以查阅 Renovate 文档中关于 packageRules 的配置选项。

我主要配置了自动更新，不需要审阅和测试直接修改版本信息然后提交到仓库里，实现无人监守自动化。

"packageRules": [
  {
    "description": "自动合并 submodule 更新",
    "matchManagers": [
      "git-submodules"
    ],
    "matchDatasources": [
      "git-refs"
    ],
    "enabled": true,
    "automerge": true,
    "ignoreTests": true,
    "automergeType": "branch"
  },
  {
    "description": "自动合并自定义 PKGBUILD 更新",
    "matchDatasources": [
      "github-tags",
      "custom.nvchecker"
    ],
    "automerge": true,
    "ignoreTests": true,
    "automergeType": "branch"
  }
]

nvchecker

调试、配置和使用都非常简单，你只需要参考官方文档根据自己的需求配置即可。可以参考我工作流中的配置。

因为我想确保 nvchecker 在检查结束版本信息后 Renovate 能够第一时间获取并更新（如果是通过 GitHub Apps 引入的 Renovate，最差的情况是 Renovate 和 nvchecker 同时运行计划任务，而 Renovate 开始得稍微早一点导致 nvcheker 获取到的新版本信息要在下一次计划任务后 Renovate 才会更新 PKGBUILD），所以我将 nvchecker 与 Renovate 放在一起并且 Renovate 使用了自托管方案。

后期我考虑直接将 nvchecker 的结果直接作为 Renovate 的输入，这样就能少一次 commit。

Workflows

~~云原生害人不浅，调试老费劲了~~

我只在 zaggash 他的工作流基础上做了些修改，舍弃了可复用性、写死了部分变量（~~变成了自己讨厌的模样~~）。

部分改进：

添加 pacman-contrib 包，使用 updpkgsums 而不是 makepkg -g 更新文件校验值，因为后者如果 PKGBUILD 没有在最后一行换行则有可能无法更新校验值
使用 yay 缓存减少构建时间
引入自己的仓库，补全自有仓库的内部依赖（总感觉 yay 在选择安装存在于自有 AUR 与官方 AUR 中的包时有奇怪的依赖关系）

部分坑：

要使用没有密码的 GPG 私钥，因为在 build_packages 环节使用数组进行构建，如果使用 crazy-max/ghaction-import-gpg action 来导入有密码的私钥，就相当于在一个系统里多次导入删除（？），总之要相信前人的智慧。

包存储

即使我现在使用 R2 作为存储后端，我也还是推荐使用 GitHub Releases 存储更为方便（如果你的网络条件良好）。不仅在构建时自己引入自己时不会触发奇怪的速率限制，而且后期可以通过 x86_64、aarch64 等 tag 来实现多架构、多平台支持。

关于 R2 使用的 actionryand56/r2-upload-action，其中的 keep-file-fresh 功能是我第一次给人提功能性 PR，而且还是在我丝毫不懂 js 然后用 GPT 帮我写的情况下提的，感谢这位开发者的不杀之恩🙏。

小结

我的相关仓库在这 CAB233/myAUR ，欢迎使用和提出意见。

已知问题

构建失败的包会从源仓库里直接消失（不论是 R2 还是 Releases 存储方案）。
第一次引入 PKGBUILD 中若引用自有仓库的依赖，需要多次构建才能满足依赖。
更新 yay 缓存需要手动删除旧缓存、触发新构建。

简短的使用方法

所有相关的文件都在.github 文件夹中，其中的 new_ver.json 可以删去
其他文件中需要你自己根据需求修改被我写死的变量，例如源仓库名称
手动触发一次 yay 缓存构建和 nvchecker 结果输出
如果你不在意 nvchecker 与 Renovate 之间的更新延迟，可以直接使用 GitHub Apps 版本的 Renovate，然后 renovate.json 中的 "onboarding"、"requireConfig"、"username"、"gitAuthor"、"platform"、"repositories" 这些字段都可以删去

在仓库根目录下使用 git submodule 引入 AUR 现有包（这样只有 PKGBUILD 是最新的，版本并不一定是上游最新的）或者新建个文件夹然后塞入自己的 PKGBUILD

# 文件结构
.
├── aliyunpan-odomu-bin
│   ├── alixby.desktop
│   ├── app.asar
│   └── PKGBUILD
├── cachyos-keyring
    ├── cachyos-keyring.install
    └── PKGBUILD

🎉开始自动之旅吧