平台 Release 指南

发版完成后自动（或单独）在代码平台上创建 Release，Release 描述就是对应版本的 changelog 内容。两种使用方式：

1. 随发版自动创建：安装平台包（@vill-v/bumpp-gitee 等，见安装 · npm），或发版时加 --provider，bump 完成后自动创建
2. 单独补发：vbumpp release <version>（见失败重试）

支持的平台

配置 token

在平台上创建 Release 需要对应平台的 access token。本机使用录入一次即可：

vbumpp token set gitee

查看和删除：

vbumpp token list
vbumpp token remove gitee

CI 环境不用录入，直接给环境变量：

GitHub Actions 里直接用内置的 ${{ secrets.GITHUB_TOKEN }} 即可。token 的优先级：本机录入 > 环境变量 >（仅 GitHub）gh auth token；gitlab 的本机录入再细分两级——当前配置 gitlab.host 的精确条目优先，provider 级 gitlab 条目回落（见下文）。

自建 GitLab 实例

在项目配置里指定实例地址：

# .vbumpprc.toml
[gitlab]
host = "https://gitlab.example.com"

host 保留端口与路径（兼容 relative-url-root 部署）；显式 http:// 原样保留，覆盖内网纯 HTTP 实例。host 写法宽松：gitlab-a.com、https://gitlab-a.com/、HTTPS://GitLab-A.com 归一为同一地址（无 scheme 自动补 https://，显式 http:// 原样保留，端口与路径保留）。

多个私有 GitLab 实例

每个仓库配各自的 gitlab.host，token 按实例逐一录入（host 作用域条目）。两个私有实例与 gitlab.com 并存的完整形态：

# 两个私有实例各录一份；gitlab.com 用 provider 级条目
vbumpp token set gitlab --host https://gitlab-a.com
vbumpp token set gitlab --host https://gitlab-b.com
vbumpp token set gitlab

# 仓库 A 的 .vbumpprc.toml
[gitlab]
host = "https://gitlab-a.com"

# 仓库 B 的 .vbumpprc.toml
[gitlab]
host = "https://gitlab-b.com"

录入的 --host 与配置的 host 都不要求写法精确一致，按上节的归一规则匹配（gitlab-a.com、https://gitlab-a.com/、HTTPS://GitLab-A.com 归一为同一条目）。查看与删除同样按实例进行：

vbumpp token list --host https://gitlab-a.com    # 只看某个实例
vbumpp token remove gitlab --host https://gitlab-a.com
vbumpp token remove gitlab --all                 # 自定义 host 多了一键清

gitlab 的 token 解析链（逐级回落，全部缺失才报错并提示对应的 --host 录入命令）：

失败重试

发版流程中 changelog、commit、tag、push 都成功了，只有创建 Release 失败（网络抖动、token 过期）时，不需要重新发版：

# token 过期就先重新录入
vbumpp token set gitee

# 然后单独补发这个版本的 Release
vbumpp release 5.1.0 --provider gitee

release 命令会从 changelog 文件取出 5.1.0 这一节作为 Release 描述——路径与 bump 主命令同一套解析（-o 优先，未给时读配置的 changelog.output，缺省 CHANGELOG.md）。执行前会检查本地存在 v5.1.0 的 tag、且 changelog 里有这一节。