Closed trim21 closed 2 months ago
v1.6.1.2657-7-g6f07eb1a
不能用于version字段,会导致用户无法加载插件
把v1.6.1.2657
后面的部分截掉作为manifest的版本呢?把完整的显示在左下角。
2664和2657中间的差可以考虑发10个空白commit跳过去(
感觉也不是很好。
如果仅考虑当前分支的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, '');
还有一个相关的问题是PR会产生一个比dev分支还大的版本号,很多用户只看数字结果安装了PR的版本。
一个折中的操作,我觉得可以这样:
目前在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
这样递增的结果。
测试例见:
感觉可以
一个折中的操作,我觉得可以这样:
目前在
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
其实看action的标签也就可以了啊
其实看action的标签也就可以了啊
你说的有道理,但就是有人不看...
咋close了,本地自己编译的版本号不对的问题还没解决(
@gm-fire 通常是只懂得看版本号,只认数字大小
咋close了,本地自己编译的版本号不对的问题还没解决(
我觉得会本地编译的人,应该知道build base吧
我大体上同意 @Rhilip 的做法, https://github.com/pt-plugins/PT-Plugin-Plus/issues/1890#issuecomment-2130784997 本地 commit 存在 merge 和 squash 单纯靠 git count 算出来肯定是会变的, 不过对于会编译会 commit 的人, 这个好像也不是什么问题. 或者在版本号里面加一位用于区分 release, daily build, pr, mr, local build, dev
现在的 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。可能造成一些困扰。