利用 GitHub Actions 自动化构建和发布 Qt 程序的一点经验

前一阵子 GitHub 正式发布了 Actions 功能来提供内置的持续集成和持续发布。而我正好最近在利用 Qt 写数字图像处理的作业，就想利用这个机会尝试一下基于 GitHub Actions 的持续集成。

当然，有问题首先是找轮子。很快我就找到了 jaredtao/HelloActions-Qt，以及相关的几篇博客文章^{[1] [2]}。照猫画虎很快就把各个平台下的自动构建弄成了。但那篇关于自动发行的文章^[2:1]对多配置下 create-release 重复执行导致失败这一问题的解决方案不太令我满意，总觉得太繁琐了，而且我对其中所用的 PowerShell 也不熟。不过这个问题显然不是特殊情况，想必也曾有人就此提出了问题，而也许已经有别人回答了更好的解决方案也不一定。果不其然，早就有人在 create-release 的仓库下的 issues 中提出过这个问题，并且这个 issue 尚未关闭，也就是并没有一个非常令人满意的解答。不过，其中有一个回答^[3]给我一点启发，它将使用多种配置的发布任务与创建 release 的任务分开，而通过 upload-artifact 和 download-artifact 来传递 release URL。另一个关联的仓库也有人给出了类似的思路^[4]：

1
2
3
4
5
6
7
8
9

build(mac)       build(linux)        build(win)
    │                  │                 │
    └──────────────────┼─────────────────┘
                       │
                create_release()
                       │
    ┌──────────────────┼─────────────────┐
    │                  │                 │
upload(mac)       upload(linux)      upload(win)

不过这种任务结构让构建和上传两个阶段的文件对应变得麻烦起来。受此启发，我想到了另一种可能——create_release()真的一定要在build(...)完成之后才能进行吗？因为我们需要创建 release 的时候一定是在发布 tag 的时候，这时我们通常已经在 commit 时检验过一遍是否通过构建/测试了，因此不妨将create_release()提前，于是有

1
2
3
4
5
6
7

                create_release()*
                       │
    ┌──────────────────┼─────────────────┐
    │                  │                 │
 build(mac)        build(linux)       build(win)
    &                  &                 &
upload(mac)*      upload(linux)*     upload(win)*

*表示只在发布 tag 的时候才会进行这个步骤。这里将build(...)和upload(...)两个阶段合在同一个job中，便于传递文件。最终配置如 .github/workflows/build.yml 所示。