用 git describe --tag 代替现有的git.count() % 65535 作为版本号

[trim21]

现在的 git.count() 是用过 git rev-list --all --count 计算出来的，其他分支的commit也会计算在内，导致如果本地有其他分支的话哪怕是同一个commit也会产生不同的版本数字。

建议使用 git describe --tag 代替，这样生成版本号是 v1.6.1.2657-7-g6f07eb1a，从上一个 tag 开始计算的，不会受到其他分支的影响。

有一个潜在问题是目前的 git.count() % 65535 是 2664，所以会从2664倒退回2657。可能造成一些困扰。

[Rhilip]

v1.6.1.2657-7-g6f07eb1a 不能用于version字段，会导致用户无法加载插件

refs: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/version#version_format

[trim21]

把v1.6.1.2657后面的部分截掉作为manifest的版本呢？把完整的显示在左下角。

2664和2657中间的差可以考虑发10个空白commit跳过去（

[Rhilip]

感觉也不是很好。
如果仅考虑当前分支的commit数量，可以直接弃用git-rev-sync提供的git.count()方法，改用 node:child_process 的 childProcess.spawnSync 方法执行 git rev-list HEAD --count 命令会好些。
还可以减少dev依赖。

import childProcess from "node:child_process";
const build_number = childProcess.spawnSync('git', ['rev-list','HEAD','--tag']).stdout.toString('utf8').replace(/^\s+|\s+$/g, '');

[trim21]

还有一个相关的问题是PR会产生一个比dev分支还大的版本号，很多用户只看数字结果安装了PR的版本。

[Rhilip]

1. 我一贯是不推荐普通用户使用pr过程中的action构建产物。
2. 从pr的角度，如果使用merge、rebase（目前使用）而非squash（合并成一次），就dev分支来说，最终还是会导致第四位patch version数字变大的，我个人是认为不用做大的修改。

---

一个折中的操作，我觉得可以这样：
目前在actions/checkout@v4，为了获取git rev-list --all --count的值，我们使用的是 fetch-depth: 0 。
则可以使用 github.event_name 等字段来判断，如果是 pull_request 类型，则将fetch-depth值更新为 1，这样对pr过程中的action构造产物，其构建的版本号永远是 1.6.1.1。
而对于正常dev更新的，其版本号是1.6.1.2853这样递增的结果。

测试例见：

• pr: https://github.com/Rhilip/PT-Plugin-Plus/actions/runs/9233176310
• mr: https://github.com/Rhilip/PT-Plugin-Plus/actions/runs/9233190667

[trim21]

感觉可以

[cddjr]

一个折中的操作，我觉得可以这样：

目前在actions/checkout@v4，为了获取git rev-list --all --count的值，我们使用的是 fetch-depth: 0 。

则可以使用 github.event_name 等字段来判断，如果是 pull_request 类型，则将fetch-depth值更新为 1，这样对pr过程中的action构造产物，其构建的版本号永远是 1.6.1.1。

而对于正常dev更新的，其版本号是1.6.1.2853这样递增的结果。

赞同这个折中方案，避免pr的版本号大于dev

[gm-fire]

其实看action的标签也就可以了啊

[trim21]

其实看action的标签也就可以了啊

你说的有道理，但就是有人不看...

[trim21]

咋close了，本地自己编译的版本号不对的问题还没解决（

[cddjr]

@gm-fire 通常是只懂得看版本号，只认数字大小

[Rhilip]

咋close了，本地自己编译的版本号不对的问题还没解决（

我觉得会本地编译的人，应该知道build base吧

[IITII]

我大体上同意 @Rhilip 的做法, #1890 (comment)
本地 commit 存在 merge 和 squash 单纯靠 git count 算出来肯定是会变的, 不过对于会编译会 commit 的人, 这个好像也不是什么问题. 或者在版本号里面加一位用于区分 release, daily build, pr, mr, local build, dev