Workflows: Cleaner Docker builds, support for manual exec and pre-release

[Meo597]

• 中间产物用 digest 而非 -usa 这种临时标签来标记，这样不污染 registry，专治 @RPRX 强迫症
• pre-release 时不打 latest 标签，只有版本号
• pre-release 转为 latest 时自动打 latest
• 支持手动运行

---

[Meo597]

分别测了下 手动运行、pre-release、pre改latest都能正常触发build

[Meo597]

prereleased 事件有 bug，如果开个草稿再转发布，不能正常触发事件 这是 github 问题，早几年就有人发现了官方一直没修 但 released 事件就一切正常，没有草稿 bug

因此只能监听 published，它在 pre 草稿转发布时能正常触发 但如果只监听这个又会导致已发布的 pre-release 取消或勾选 latest 时不能再次触发事件 所以必须还得再监听 released

然后同时监听这两个，又会出问题，因为 published 包括 released 所以如果直接发 latest-release 版本，会立即构建两次映像，而且是同时进行的 这样在极端情况下，比如直接发一个 latest 版 v1.2.3，有极小概率 1.2.3 和 latest 标签不在同一个映像上

所以要加判断把直接发 latest release 时触发的 published 构建取消掉 这样问题就解决了，虽然看起来怪怪的但没有 bug

---

另一个设计缺陷是 github.event.release.prerelease github 没有设计 github.event.release.latest 而实际上发版有三种状态：latest、prerelease、什么都不勾选

如果用 github rest api 去获取状态太麻烦了 因此现在什么都不勾选，也被视为 latest

但是这样的话如果 v2.0.0 被设为 latest，然后把 v1.0.0 的 pre 改为 什么都不选 v1.0.0 的 docker image 会被错误地设为 latest 实际上从没见 @RPRX 这么干过

而且较真起来的话，因为事件只能被触发一次 如果对 release 反复编辑、切换 pre 和 latest 勾选状态，根本没法让 docker 和 release 同步

现在的做法在保证代码简单的情况下，覆盖了常规场景 然后真有上述情况发生，可以直接手动构建 docker image

---

总结一下，

没问题的场景：

• 草稿的 pre-release -> 转为发布
• 没有草稿直接发布 pre-release
• 草稿的 latest -> 转为发布
• 没有草稿直接发布 latest
• 已发布的 pre 转 latest

可能需要手动运行 workflow 的场景：

• 在已发布版本上反复勾选/取消 pre-release、latest 或 转为草稿 —— 只能触发一次
• 草稿的 什么都不选 -> 转为发布 —— 会被视为 latest
• 没有草稿直接发布 什么都不选 —— 会被视为 latest
• 已发布的 pre 改为 什么都不勾选 —— 会被视为 latest
• 已发布的 什么都不勾选 改为 latest —— 不会再次运行，之前已被视为 latest

[RPRX]

但是这样的话如果 v2.0.0 被设为 latest，然后把 v1.0.0 的 pre 改为 什么都不选 v1.0.0 的 docker image 会被错误地设为 latest 实际上从没见 @RPRX 这么干过

~~印象中似乎没这么干过~~

~~希望这次不会被背刺~~

~~可以给 GitHub 提 bug~~

[RPRX]

~~以后哪天想起来了再向 GitHub 申请把旧包都删了吧，不然太乱了~~

[Meo597]

这个包稳的

测试覆盖率 100%，各种刁钻场景都考虑过了 即便像以前那样 github 出 bug 取不到 ref，还有手动执行来兜底

所以提工单的时候可以直接删整个 package，这样或许他们好操作一点 然后这边手动运行此 workflow 选 tag 单发 docker 的版

自上次破坏性重构以来 docker 使用量翻了七八倍 看来大家对 distroless rootless 还是认可的

目前我还发现 docker 版因为编译参数缺少 git hash 显示的是 custom，要不要完善

另外 teddysun 的镜像用私人服务器编译，有被黑供应链投毒风险 要不要提醒一下，或者我弄个 -alpine 标签出来？

[RPRX]

@Meo597 出事故了，v25.7.25 是直接 release，镜像编译失败

[RPRX]

re-run 无效，但我把它改为 pre 又改为非 pre 的那一刻，它开始编译了

[RPRX]

成功了，也自动被设为了 latest，但就是说直接 release 非 pre 这种情况需要一个修复

[Meo597]

Error: Could not determine a valid tag source. Input tag and context tag (github.ref_name) are both empty.

SOURCE_TAG="" if [[ -z "$SOURCE_TAG" ]]; then SOURCE_TAG="" fi

不知道为什么又没取到 ref，这个是你发版的 tag 号 这种情况 rerun 出错的任务是不行的

要么手动运行，要么 pre 来回改就能触发个新任务就没问题了

这是 github 偶发性 bug 但是频率也太高了

我等下看看别的项目都是怎么获取 tag 的

[Meo597]

https://github.com/orgs/community/discussions/64528#discussioncomment-12978855

We can see that this is still a popular discussion we want to add additional info as to why the github.ref may be empty so we can guide users to the correct documentation.

Following @arafajs reply It's important to note that the behavior of github.ref_name depends on the event that triggers the workflow. For instance:

• For push events, github.ref_name corresponds to the branch or tag that was pushed.
• For release events, the release tag can be accessed via github.event.release.tag_name, while github.ref_name might not always provide the expected value.
• For other triggers like pull_request, the variable behaves differently, often pointing to the merge branch or base branch.

We recommend reviewing the GitHub Docs on default environment variables for a deeper understanding of variable behavior across different events.

Acknowledging the users experiencing inconsistencies we have shared this feedback with our internal teams.

GitHub 的意思是：我知道我们有 BUG，正在研究，建议用 github.event.release.tag_name 我稍后按他建议的改下试试，然后防御式的多读几个变量来获取 tag，总有一个能用