2022-26: 哑巴英语首次开口

Iteration 16 从 6 月 18 号开始到 7 月 3 号结束，为其两周。这个周期有意思的事情不少，其中印象最深刻就是哑巴英语首次开口的经历。

与 Mergify 的采访

Mergify 是一个 Pull Request 自动化工具，主要的功能包括 Auto Merge，Merge Queue，PR Actions 等。Databend 最早使用他来解决 PR 自动合并的问题，后来使用范围逐渐扩大，现在已经将所有的 PR 相关的自动化流程都交由 Mergify 处理。

我们使用 Merfigy 完成如下工作：

Auto Merge & Merge Queue 自动更新 PR，确保所有 PR 都基于 main 分支运行测试后再合并
出现冲突的时候请求作者进行修改
检查 PR 的标题和内容是否符合要求并请求作者进行修改
根据语义化的 PR 标题自动添加对应的标签供生成 Release Note 使用

详细的配置参见 mergify.yml

后来受 Mergify 的邀请，我参加了跟 Mergify 同事的英文采访。这是我生平第一次参加这种纯英文的面谈，感觉非常紧张。Mergify 那边给我发来了问题列表，我对着问题列表提前准备了不少时间，拿出了自己高中背英文课文的态度把回答都背了一轮。为了防止出丑，我还跟着 Google 翻译把每一句话都读了一遍，避免发音错误。

真到了采访的时候感觉也就那样，233333。

对面是一个法国人，同样有着自己的口音。我们最开始先寒暄了一波，提到我在中国的时候，她还兴致盎然地分享了自己去中国旅游的经历。她去过的地方还真不少，北京，成都，上海什么的都去过，感觉挺有意思的。后面感觉就自然多了，基本上按照提纲一问一答，我还临时发挥了不少，最后采访就在一片欢声笑语中结束了。

这次采访的几个感想：

感谢女朋友一直拉着我看英美剧，感觉自己说起话来没有那么僵硬。
听不听得懂是别人的事情，张不张口是自己的事情。只要敢说，问题就解决了一大半，语法啊，发音啊，咬字啊都是小问题，真正的口头交流没人会闲着没事干纠正你的发音问题。
感觉语音交流很有意思，以后希望能多参加一些类似的访谈节目，免得自己长期在家语言沟通能力退化。

Fusebot 退休

Databend 过去使用 fusebot 来完成各种自动化操作，比如 Nightly Release，Auto Label 和 Auto Merge。但是维护这样一个自动化的 bot 是一件很无聊的事情：简单的事情不用它也能搞定，麻烦的事情实现起来很费劲。所以后来我们决定尽可能使用现成的 SaaS 服务来解决这些需求，不再自己重复造没有意义的轮子。正如前面所提到的，Merfigy 已经逐步取代了 fusebot 的功能，距离彻底替代只差一个 Nightly Release 自动创建。

为了完善整个 Release 的流程，我发起了 proposal: Semantic Release，主要变化有两处：

引入 Semantic PR，要求 PR 的标题必须符合语义化的要求（过去我们是要求开发者在 PR 的描述中填写相关的项目）
使用 Github 原生的 Release Notes 生成机制，去掉对 Fusebot 的依赖

Semantic PR 基本上就是 Conventional Commits 的 PR 版本，我们通过 Merfigy 的 PR Action 来强制要求开发者必须使用合法的 PR types。不符合要求的话，Merfigy 会 comment PR 要求修改：

在这个基础上，Merfigy 可以自动的为 PR 增加对应的标签。然后就可以使用 Github 原生的 Release Notes 生成机制来配置，只需要增加一个配置文件 .github/release.yml 即可

changelog:
  exclude:
    labels:
      - pr-chore
    authors:
      - Mergify
  categories:
    - title: Exciting New Features ✨
      labels:
        - pr-feature
    - title: Thoughtful Bug Fix 🔧
      labels:
        - pr-bugfix
    - title: Code Refactor 🎉
      labels:
        - pr-refactor
    - title: Build/Testing/CI Infra Changes 🔌
      labels:
        - pr-build
    - title: Documentation 📔
      labels:
        - pr-doc

这里还有一些关于 gh 的小技巧：检查最新 release 和创建 release 相关的 action 都不是特别好用，我们可以使用 runner 中自带的 gh 命令来搞定。

获取当前最新的 release tag （注意跟 git tag 的输出是不同的）

- name: Get latest tag
  id: get-latest-tag
  run: |
    echo "::set-output name=tag::`gh release list -L 1 | cut -f 1`"    
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

创建 release：

- name: Create github release if not exist
  # Reference: https://cli.github.com/manual/gh_release_create
  run: |
    echo "Create a release for ${{ steps.generated-tag.outputs.tag }}"
    gh release create ${{ steps.generated-tag.outputs.tag }} --generate-notes -p    
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

--generate-notes 用于让 Github 自动生成 Release Note
-p 用来把当前 release 标记为 prerelease

后续只需要使用相同的 tag 来上传即可：

- name: Update release to github
  shell: bash
  # Reference: https://cli.github.com/manual/gh_release_upload
  run: gh release upload ${{ inputs.version }} databend-${{ inputs.version }}-${{ inputs.target }}.* --clobber
  env:
    GH_TOKEN: ${{ inputs.github_token }}

直接使用 gh 比引入一堆 aciton 要方便的多，完整的 workflow 参见 databend-release.yml。

这个周期比较有意思的事情就这些，我们下周再见～