持续集成

我们通常使用 push 和 pullrequest来触发Github Actions。
每一个提交都是一个 push。
当你从一个分支（例如，great_feature）提交一个pull request到另一个分支（我们的工作分支，dev），每一个在great_feature上的提交可能会触发这两个事件。
我们可以使用过滤器来关注我们所关心的事件。

在我们的工作流中，我们只向dev和master分支发出PR(pull request)，

这意味着如果我们使用过滤器筛选出dev和master分支上的commit，那么只有在 合并_ PR时才会运行工作流。

通常合并PR这种事最多也就一天一次，因此这将适合长时间运行的测试，比如我们测试用例中的冒烟测试。

下面是它的样例。
单元测试:
# 因为这个样例运行得很快，所以我们可以在每次commit的时候触发 name: unit tests on: pull_request: push: branches: - dev - master
冒烟测试:
# 因为这个样例运行得比较慢，所以我们只在合并PR到dev或者master分支的时候触发 name: smoke tests on: push: branches: - dev - master
Tauri默认在dev分支上开发，并合并到master分支发布。

通过设置这些GitHub Actions，我们会对open状态PR的每一个commit(见pull_request) 运行单元测试。

当合并PR到dev分支时，我们会同时运行单元测试和冒烟测试。

持续交付

不可变校验码（checksum）

在Github上发布之后，你依旧能够轻而易举地修改发行说明和伪影(Artifacts)。

这么做看起来很合理，但并不可靠——比如你无法保证你所看到的内容真实反应了改动。

从技术角度来说，有目的的攻击行为可能会替换掉下载链接或是校验码。

我们力求实现的是一个最佳的情况，即：

  1. 人为错误会被降至最少，但是依然能够人工干预某个实际的发行
  2. 在稳定的全球应用商店中，由机器构建的资源、更新日志和附带的安全检查都可以通过校验码校验。

为此我们设计了一个如下的工作流：

目前我们已经实现了#3到#6。

我们会手动完成#2并执行#3，然后取消剩余的自动化工作流。

  1. 有一人向dev分支提交了PR（这种事非常频繁）
    • PR包含了一个能描述变动内容和版本间变化的描述文件
  2. 创建或更新一个PR来增加变化描述
    • 这个PR会保持open状态并强制推送直到它被合并（并发布）
    • 根据变动内容更新版本号
    • 删除所有描述变动内容的文件
  3. 某个仓库管理员合并了PR到dev分支（不允许任何人直接推送）
    • 所有的测试(unit, e2e, smoke tests) 都在PR上运行
    • 如果某PR导致了测试错误则不会被合并，因此PR必须通过测试
  4. 合并到dev分支触发发布队列
    • 变更会被删除，然后创建一个向master分支的PR
  5. 向master分支的PR被合并
    • 保存代码审查(crates and yarn) 的结果
    • 保存校验码和元数据
    • 创建tarball/zip包用于发布到npm/cargo
    • 为每一个被更新的包创建release（如果版本号未更新，构建会自动跳过发布环节）
    • 通过管道向release输出审计结果和校验码
    • 上传tarball/zip
    • 异步地向IOTA tangle (feeless) 发布release[注意：这里还有一些问题待解决]

  6. 发布完成

    • master分支的代码已被更新并标记版本
    • GitHub release 页面拥有了压缩包、校验码和变更日志（如果不止一个包有更新则会有多个release）[注意：这是步骤2的一部分并且尚未完成]

      下一步

      接下来可能会在别的位置发布构建

  7. Tauri的私有verdaccio

  8. IPFS
  9. PureOS Gitlab
  10. GitHub Packages

我们还可以再做一些有意思的事，比如为我们的release签名，包含release中的哈希甚至是向区块链发布这个信息，这样人们可以很容易地验证这个信息的真实性。

在区块链上发布也不失为一种能够使你确信你在GitHub上下载到的文件可靠的方式。

IOTA基金会已经创建了能向他们的区块链发布release的Github Action工作流模板，

虽然目前还有许多的问题，但是未来可期。