Rhilip

https://crontab.guru/#0_9_*_*_0

我个人不太建议硬编码 `+45` 直接bump version到 `1.6.2` 我觉得会更好（因为之前有次删掉 next 分支的时候就是这么操作的

为什么version的最后一位要重置回1？ 从设计上这一位就是commit的数量。目前action的设计中，对pr的已经将其固定为1，而mr的和正常的半月构建都是`git.count()`，能够反映更新情况。 而大版本号从`1.6.1`跳到`1.6.2`能避免因为commit数量只统计当前分支（即从`git.count()` 改为 `git rev-list HEAD --count`）而导致的版本混乱。

`v1.6.1.2657-7-g6f07eb1a` 不能用于version字段，会导致用户无法加载插件  refs: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/version#version_format

感觉也不是很好。 如果仅考虑当前分支的commit数量，可以直接弃用git-rev-sync提供的`git.count()`方法，改用 node:child_process 的 `childProcess.spawnSync` 方法执行 `git rev-list HEAD --count` 命令会好些。 还可以减少dev依赖。 ```js import childProcess from "node:child_process"; const build_number = childProcess.spawnSync('git', ['rev-list','HEAD','--tag']).stdout.toString('utf8').replace(/^\s+|\s+$/g, ''); ```

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

> 咋close了，本地自己编译的版本号不对的问题还没解决（ 我觉得会本地编译的人，应该知道build base吧