CHANGELOG.md

案例


## [1.0.1.2] - 2023-03-10 
###  myproject2 _ 1.0.1:
- 初步版本 简单实现 还未优化
- fix warning 

## [1.0.2] - 2023-03-10 
 
###  mynuget _ v4.0.0.0:
- 初步版本 简单实现 还未优化
###  xxx.xxx _ v1.2.0:
- 初步版本 简单实现 还未优化
- fix warning 
###  myproject1 _ v3.2.0-beta.2:
- 初步版本 简单实现 还未优化
- fix warning 
###  myproject2 _ 1.0.0:
- 初步版本 简单实现 还未优化
- fix warning 

解析

  • 1.0.1.2 / 1.0.2 这两个是主要发版版本, 也就是您 github 页面呈现的 release 版本号.
  • myproject2 _ 1.0.1 / mynuget _ v4.0.0.0 / myproject2 _ 1.0.0 这些是工程发布版本号, 也就是您要推送到 nuget 上的包名以及版本号.
  • myproject2/mynuget 等包名必须在工程文件csproj 中指明,即 <PackageId>mynuget</PackageId>.
  • {package_name} _ v4.0.0.0 / v1.2.0 / v3.2.0-beta.2 这些版本号若带后缀,必须符合 nuget 发版规范, 比如 alpha/beta 等写法.

注意工程必须开启打包功能: <IsPackable>true</IsPackable>

原理

版本号不需要在工程文件中填写,因为模板是以 CHANGELOG.md 的节点版本为主.
比如:在以上案例中, mynuget 即将发布的版本是 v4.0.0.0 , 它将在 CI 环境中被打包成 v4.0.0.0 版本,并推送到 nuget 服务器上.

注意事项

  • 您的 CHANGELOG.md 节点名称必须与您工程文件中打包名匹配, 否则单元测试将不会推送这个包,实际上它也找不到这个包.
  • 可重复推送, 管道功能会检测包版本, 在没有高版本时它将不会推送到服务器.
  • 如果您发布的 CHANGELOG.md 中, 有多个包,但只有一个包能成功推送, 那么管道也会标识成功.

注意 CHAMGELOG.md 改完之后推送到主分支上. 如果需要更改触发条件, 配置文件在.github\workflows\release.yml

发布功能:

1. 发布 github release 信息

管道将根据 CHANGELOG.md 文件的节点版本记录自动发布 release 信息. 请将之前的版本放在注释里或者归档到其他地方,否则发新版时将会携带旧版本的信息.
重复触发管道不会有异常和例外情况,允许重复触发,每次重复触发都将会更新 release.

2. 推送 nuget

管道将根据 CHANGELOG.md 文件最后一个节点, 自动发布 nuget 包(含符号).
重复触发管道不会有异常和例外情况, 允许重复触发.

3. 归档计划

将当前的 {项目名}_VNext 计划归档到具体版本计划, 然后创建一个新的 {项目名}_VNext 计划.
重复触发管道不会有异常和例外情况, 当已存在归档计划时,管道将不会继续运行.

注意,多次触发并不会产生并发问题, 该管道功能中, 3个功能为并发执行, 但多管道运行需要排队.

4. 覆盖率文件上传

覆盖率文件属于同时运行的另一个管道,它将根据 project.yml 节点配置生成覆盖率配置文件.
同为 test 节点, 与单元测试不同, 配置覆盖率上传的选项为: trigger_codecov, 设置为 true 即可.
如果您的覆盖率文件生成需要特定的.NET环境, 您可以在 .github\NMS_TEMPLATE\codecov.yml.template 中进行配置.

学习与使用

1. 将项目 fork 到你的仓库中, 然后 Setting 作为模板.

2. 文章导航