基于 Github 平台的 .NET 开源项目模板 - 发布与归档 相关
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 作为模板.
