一、Loongarch（loongarch64 / Loongson）上 .NET 10
概览
发布：v10.0.100-loongarch64（tag）
发布者（自动化）：github-actions[bot]
发布时间（UTC）：2025-11-14T13:21:44Z
类型：prerelease（预发布）
目标分支：build
Release 页面正文为空（未附带额外说明），但包含一组构建产物（tar.gz 与 NuGet 包）用于 loongarch64 平台。
仓库：https://github.com/loongson/dotnet
重点说明
支持平台：loongarch64（即 Loongson CPU 架构的 Linux）。
覆盖范围：SDK、运行时（dotnet runtime）、ASP.NET Core 运行时、NativeAOT 运行时、Crossgen2、ILCompiler、Host 包和若干 native/系统库的 NuGet 包与源构建产物。
这是“预发布”构建，说明可能是针对 Loongson 社区或内部构建发布来验证在 loongarch64 上的兼容性和功能；在生产环境使用前应充分测试。
如何下载（示例）
直接使用 Release 下载 URL（示例）：
https://github.com/loongson/dotnet/releases/download/v10.0.100-loongarch64/dotnet-sdk-10.0.100-linux-loongarch64.tar.gz
或在 Release 页面通过“Assets”手动下载相应文件。
快速安装（常规 tarball 安装步骤，适用于大多数 Linux 发行版）
下载 tarball 到主机
curl -L -o dotnet-sdk.tar.gz "https://github.com/loongson/dotnet/releases/download/v10.0.100-loongarch64/dotnet-sdk-10.0.100-linux-loongarch64.tar.gz"
解压并放到系统目录
sudo mkdir -p /usr/share/dotnet
sudo tar -zxf dotnet-sdk.tar.gz -C /usr/share/dotnet
创建可执行链接并设置环境变量
sudo ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet
export DOTNET_ROOT=/usr/share/dotnet
export PATH=$PATH:/usr/share/dotnet （注：上面是常用做法，视你的发行版和安全策略调整。某些发行版或包管理器可能需要不同的步骤。）
测试建议
验证 dotnet 可执行：
dotnet --info
编译并运行一个简单的 Console 应用：
dotnet new console -o testapp && cd testapp && dotnet run
针对 ASP.NET：使用 aspnetcore-runtime 的示例应用部署与访问测试。
测试 NativeAOT、Crossgen2、以及涉及 System.IO.Ports 的功能（若你需要串口支持）。
风险与注意事项
由于是预发布版本，可能包含未解决的问题或性能/互操作性差异，建议在非生产环境先进行完整回归测试。
若你依赖第三方原生库或特定 Linux 发行版的 ABI，测试兼容性很重要。
二、RISC-V .NET 10
概览
发布标题 / 标签：10.0.100-rtm.25561.199 (tag: 10.0.100-rtm.25561.199)
发布时间：2025-11-12T00:45:00Z
发布类型：预发布 (prerelease: true)
目标分支：main
作者：github-actions[bot]（自动化构建/上传）
仓库：https://github.com/filipnavara/dotnet-riscv
附件（资产）：dotnet-sdk-10.0.100-rtm.25561.199-linux-riscv64.tar.gz
说明：这是为 Linux on RISC‑V (riscv64) 提供的 .NET 10 SDK 二进制包
简要解释
这是一个面向 RISC‑V（riscv64）的 .NET 10 SDK 的 RTM 构建包，发布为预发行版，表明它是供测试/早期试用的构建而非正式稳定发布（没有随附发布说明或变更日志）。资产名称显示这是一个 Linux 平台的 tar.gz 安装包。
三、基于GitHub Actions 流水线发布 .NET SDK
.NET 10 社区SDK（Loongarch 和 RISC-V）能够快速的同步进行构建发布，主要是从.NET 9 开始实现了基于同一套代码基线构建.NET SDK的基础设施，下面就基于 GitHub Actions 流水线发布 .NET SDK的原理与典型过程拆成几个部分来讲清楚：总体流程、关键步骤、所需凭证/基础设施、常见实现细节（包含示例 workflow 片段）、以及注意事项与最佳实践。最后我会列出如果你想要我继续可以帮你做的后续工作。
3.1、总体概念（为什么要用 CI/CD 发布 SDK）
目标：把源码编译成跨平台的 SDK 二进制/安装包（zip/tar、pkg/dmg、msi/deb/rpm 等），做签名、生成校验和、上传到发布位置（GitHub Release、Azure Blob/Storage、官方 feed 或镜像站），并更新安装脚本/渠道（例如 dotnet-install 脚本或网站上的版本清单）。
GitHub Actions 作为自动化引擎：触发（tag/release、手动/dispatch、定时）→ 构建 → 测试 → 打包/签名 → 发布 → 后置更新/通知。
区分 CI（PR 验证、快速构建）与 Release 流水线（正式标签触发、全量测试与签名、需要敏感凭据）。
3.2、典型流水线阶段（按顺序）
触发（Trigger）
常见触发：push tag（例如 v10.0.0-preview1 或 v10.0.0），release created、workflow_dispatch（手动触发）、或从发布协调器触发的 API 调用。
Release 流程通常只在经过人工审核或特殊权限后允许写入敏感凭据/生产证书的 runner 上运行。
环境准备 / Checkout
使用 actions/checkout 拉代码。
设置必要的运行环境（选择 runner：ubuntu-latest、windows-latest、macos-latest 或自托管 runner；很多 SDK 发布依赖自托管 Windows/macOS 机器来完成代码签名或生成 platform-specific installer）。
拉取子模块或相关 repo（例如 runtime、libraries、installer 模块等）。
引导/依赖安装
运行构建脚本的引导（对 .NET 常见是 repo 镶嵌的 build.ps1/build.sh 或使用 repo-toolset）。
如果是交叉构建，可能需要先安装早期版本的 dotnet 来做 bootstrapping（使用 dotnet-install 脚本或 actions/setup-dotnet）。
编译（Build）
多 OS/arch 的矩阵构建（x64/arm64；Windows/Linux/macOS）。
构建会生成 runtime、host、sdk 二进制，可能会调用 msbuild/dotnet build/clang/gcc 等。
构建输出分目录（sdk、shared runtime、hostfxr、hostpolicy、packs 等）。
测试（Tests）
单元测试、集成测试、回归测试。
对 Release 通常会更多：较长时间的 E2E、兼容性测试、安装与卸载测试、sample app 运行测试。
有时会在不同平台上做“smoke tests”来确保包可以实际执行。
打包（Package）
生成 SDK zip/tar、NuGet 包、Windows MSI、macOS pkg 或 dmg、Linux deb/rpm。
生成校验和（sha256/sha512），并生成版本元数据（manifest/json），用于后续下载/安装脚本解析。
签名（Code/Artifact Signing）
对可执行文件、安装包进行代码签名（Windows 使用 SignTool + EV 证书、macOS 使用 codesign + notarize、包使用 GPG 签名或微软的签名流程）。
这一步通常需要访问机密（证书、私钥、时间戳服务），生产环境多用自托管 runner 或安全的签名服务。
发布（Publish / Upload）
上传构建产物到发布存储：
GitHub Releases（创建 release 并上传 asset）
Azure Blob Storage / CDN（供下载安装）
官方 feed（如 NuGet、internal feeds）
镜像站、内部渠道
更新安装脚本或版本清单（例如更新 dotnet-install 的 JSON 或网站的下载页面），并将变更推送到相应 repo（可能需要另一个工作流或 API 调用）。
后置工作（Post-release）
通知（Slack 邮件）/更新文档/创建 release notes。
CDN 缓存失效、镜像同步。
监控发布后的用户反馈 / 自动化探测（如 health checks、telemetry 验证）。
3.3、关键基础设施与凭据
自托管 runners：用于访问私有签名证书或生成 macOS notarize（Apple 只在 macOS 上能做）。
Secrets（GitHub Secrets / Azure Key Vault / HashiCorp Vault）：
代码签名证书（.pfx 或硬件密钥访问的凭据）。
Apple Developer 密钥、notary credentials。
GPG 私钥（如果用 GPG 签名）。
Azure Storage connection string / SAS token / Azure AD client secret（用于上传到 blob）。
NuGet API keys（发布包）。
GitHub token（用于创建 release、上传 release assets，注意权限限定）。
时间戳服务 / Timestamp URLs：在代码签名时保持长期有效性。
Artifact 存储与 CDN：用于高速下载并支持回滚/版本管理。
3.4、常见实现细节与自动化点
构建并行化：用矩阵 jobs 构建多个 OS/arch，或把某些构建拆成并行 job 来加速。
依赖缓存：actions/cache 缓存 NuGet 包和构建中间产物，减少重复耗时工作。
可复现/可审计：
生成 SBOM（软件物料清单）。
生成构建元数据（构建ID、commit、时间戳），并写入 release notes/manifest。
SLSA/Provenance：签署构建证明（使用 sigstore 等）以保证来源可验证。
Release gating 与手动审批：
对 release job 使用 environment protection rules（需要手动批准或审核）。
对访问敏感 secrets 的 job 限制为特定环境或 runner。
打包的跨平台差异：
Windows：MSI/ZIP/EXE，需 SignTool，可能还要生成 installer bootstrapper。
macOS：pkg/dmg, codesign + notarize（需要 Apple Notary）。
Linux：deb/rpm，不签名二进制但可以签署包（RPM签名、GPG）并上传到 apt/yum repo。
发布渠道管理：
维护“preview”和“stable”频道：通过不同 tag/manifest 决定 dotnet-install 脚本哪个版本被默认下载安装。
有时候会分阶段发布（先到 Canary/staging/insider，再到 public stable）。
