尧图网页设计 
Envoy Mobile 版本发布指南从版本号管理、CI 自动化到 GPG 密钥维护的完整工作流【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy导读本文基于 mobile/docs/root/development/releasing/releasing.rst 撰写系统梳理 Envoy Mobile构建于 Envoy 核心网络层之上的跨平台客户端网络库从准备发布到发布产物再到密钥维护的完整工作流。你将掌握如何正确提交发布前置 PR版本号 版本历史、打 tag 后 CI 如何自动产出 iOS/Android 产物并发布到 Maven 与 CocoaPods、预发布版本的X.Y.Z.{yyyymmdd}命名规范以及 GPG 签名密钥的生成、导出与在 GitHub Secrets 中的轮换方法。文中所有关键环节均附当前仓库源码佐证可直接对照落地。发布前准备工作先合入版本号与版本说明正式发布cutting a release之前需要先提交并合入一个 PR其中包含两处强制变更提升 mobile/VERSION 文件中的版本号。当前仓库中该文件内容为0.5.0即最新正式版本的版本号来源也是后续所有 CI 校验、文档发布判断的依据。在版本历史文档 mobile/docs/root/intro/version_history.rst 中补充本次发布的概述。关于版本历史文档的组织方式仓库中的 mobile/RELEASE.md 给出了更细的实操约束在文件顶部新增一个Pending Release小节内含Bugfixes:与Features:等分类条目将旧的Pending Release小节改为带版本号和发布日期的形式例如0.5.0 (September 2, 2022)用git log \git rev-list --tags --max-count1..HEAD 核对自上次发布以来的所有变更是否都已写入当前发布说明若构建的是季度发布quarterly release还需在版本历史中注明所基于的 Envoy 上游 tag例如0.4.5版本标注了 Based off Envoy v1.21.0。从 mobile/docs/root/intro/version_history.rst 的既有记录可以看到每条发布说明的标准形态以版本号 日期为小节标题按Breaking changes、Bugfixes、Features分类罗列并对 API 变更给出精确的接口名与对应 issue 编号。这是评审者与下游用户判断升级影响面的第一手资料。此外根据 mobile/RELEASE.md非季度发布只需同步VERSION与版本历史季度发布还需额外确保 Envoy checkout 指向最新的 Envoy 上游发布 tag并同步EnvoyMobile.podspec中的版本号。将这些变更以 PR 形式提交、评审、合入后才进入发布环节。发布与产物发布打 tag 触发全自动流水线前置 PR 合入后即可为本次发布打 tag例如v0.5.0。打 tag 的行为会在 main 分支上自动触发一组 CI 任务完成以下四件事创建 GitHub Release并附带 iOS 与 Android 构建产物将版本发布到 Maven 与 CocoaPods 分发渠道发布最新版本的 Envoy Mobile 文档。发布物的构成与手工补充步骤尽管 CI 会自动生成发布物mobile/RELEASE.md 仍记录了发布者需要跟进的人工环节等待对应 tag 的 artifacts workflow 跑完下载envoy_android_aar_sources、envoy_ios_cocoapods、envoy_ios_framework三份产物回到已创建的 release 页面将其编辑上传挂载。文档发布的 tag 校验逻辑文档的自动化发布由 mobile/docs/build.sh 驱动其中体现了清晰的版本策略只有形如vX.Y.Z的正式发布 tag 才会发布带标签的文档DOCS_TARGET//docs且强制校验 git tag 与VERSION文件内容一致v${VERSION_NUMBER}必须等于GITHUB_REF_NAME同时要求version_history.rst中存在当前版本号形如vX.Y.Z.ddmmyy的预发布 tag 不发布带标签文档走普通//docs:html目标文档产物输出到generated/docs通过envoy//tools/tarball:unpack解包发布。这解释了为什么预发布版本虽然每周发布却不会污染正式文档站点。Maven 发布的实现细节MavenSonatype OSSRH的发布逻辑沉淀在 mobile/ci/sonatype_nexus_upload.py 中可作为理解CI 自动发布内部机制的源码参考通过READWRITE_USER/READWRITE_API_KEY环境变量做 Basic 认证目标为https://oss.sonatype.org/service/local/staging构件坐标为io.envoyproxy.envoymobile发布文件清单为envoy.aar、envoy-pom.xml、envoy-sources.jar、envoy-javadoc.jarSonatype 要求所有上传构件经 GPG 签名因此脚本支持--signed_files传入.asc签名文件如envoy.aar.asc这正是本文后半部分 GPG 密钥管理的直接业务场景上传流程遵循 Sonatype 标准 staging 生命周期创建 staging repository → 上传文件与 SHA-256 校验文件 → closefinish→ promoterelease任一环节失败会尝试 drop staging repository 并终止网络层对 5xx 错误最多重试 500 次每次间隔 1 秒注释中说明这是为了应对 Sonatype 频繁失败的实际经验支持--local模式将构件安装到本地~/.m2/repository/io/envoyproxy/envoymobile/便于发布前自测。Android AAR 产物的构建规则见 mobile/bazel/android_artifacts.bzl由于 bazelandroid_library的隐式 aar 输出不会扁平化传递依赖且 kotlin 规则会生成多层底层库导致 classes.jar 为空该宏手工组装 aar产出 aar、pom、sources.jar、javadoc.jar 四类文件与上传脚本的文件清单一一对应。预发布版本号规范周更与日期后缀预发布pre-release按周发布版本号方案为X.Y.Z.{yyyymmdd}例如 2020 年 1 月 25 日的预发布版本即为0.3.1.20200125。要点解读X.Y.Z对应当前正式版本的语义化版本号{yyyymmdd}是八位日期后缀用于在同一正式版本号下区分每周的预发布构建该后缀使预发布 tag 天然不满足 mobile/docs/build.sh 中^[0-9]\.[0-9]\.[0-9]$的正则校验从而自动跳过带标签文档的发布避免预发布污染正式文档站点当前仓库 mobile/VERSION 中的0.5.0即对应的正式版本基线。GPG 密钥签名密钥的生成与轮换流程由于 Maven Central 要求上传构件必须经过 GPG 签名见上文 mobile/ci/sonatype_nexus_upload.py 对--signed_files的说明Envoy Mobile 使用专用的 GPG 密钥对发布物签名。当密钥需要更新轮换时按以下步骤执行1. 生成新的密钥对$ gpg --full-generate-key按交互式提示完成生成算法、长度、有效期等。生成过程中会设置 PASSPHRASE务必记下该口令后续需要写入 GitHub Secrets。2. 确认密钥身份信息生成密钥时Real Name填写Envoy Release Botemail 填写noreplyenvoyproxy.io即发布机器人专用身份便于审计与辨识。3. 查看并导出私钥$ gpg --list-keys $ gpg --armor --export-secret-keys $KEY_ID先用--list-keys找到新密钥的 KEY_ID再以其导出 ASCII armored 格式的私钥即步骤 5 中用于签名/解密的密钥材料。4. 重新分发公钥$ gpg --keyserver keyserver.ubuntu.com --send-keys $KEY_ID将新公钥上传到公钥服务器如 Ubuntu keyserver使验证方能够获取公钥校验签名。5. 更新 GitHub 仓库 Secrets请 Envoy GitHub 仓库管理员更新以下两个 SecretsEM_GPG_PASSPHRASEpassphrase noted down from step 2 EM_GPG_KEYsecret key from step 5EM_GPG_PASSPHRASE步骤 2 中记录的口令EM_GPG_KEY步骤 5 导出的 ASCII armored 私钥内容。这两个 Secret 是 CI 在发布时对构件进行 GPG 签名生成.asc签名文件并上传 Sonatype的凭据来源。轮换完成后旧的密钥/口令即可废弃。结合仓库实践的发布自检清单将 mobile/docs/root/development/releasing/releasing.rst 与 mobile/RELEASE.md 合并可得到一份完整的发布执行清单阶段动作仓库依据准备更新 mobile/VERSION 版本号mobile/RELEASE.md准备在 mobile/docs/root/intro/version_history.rst 新增/更新发布说明同上0.5.0 (September 2, 2022)小节为范例准备季度发布同步 Envoy 上游 tag 与 podspec同上发布打 tag正式版vX.Y.Z触发 CI原文档 mobile/docs/build.sh发布CI 创建 GitHub Release、iOS/Android 产物、Maven/CocoaPods 发布、文档发布原文档跟进下载envoy_android_aar_sources、envoy_ios_cocoapods、envoy_ios_framework并挂载到 releasemobile/RELEASE.md密钥按 GPG 流程轮换EM_GPG_PASSPHRASE/EM_GPG_KEY原文档其中文档发布依赖 mobile/docs/build.sh 对 tag 名与 VERSION 文件的一致性校验Maven 上传依赖 mobile/ci/sonatype_nexus_upload.py 的 staging 流水线与 GPG 签名文件Android 构件由 mobile/bazel/android_artifacts.bzl 手工组装 aar。发布者只要按表推进即可在 CI 自动化与人工核对之间形成闭环保证每个版本从代码合入到终端用户可下载的完整链路可追溯、可复现。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Envoy Mobile 版本发布指南：从版本号管理、CI 自动化到 GPG 密钥维护的完整工作流
Envoy Mobile 版本发布指南从版本号管理、CI 自动化到 GPG 密钥维护的完整工作流【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy导读本文基于 mobile/docs/root/development/releasing/releasing.rst 撰写系统梳理 Envoy Mobile构建于 Envoy 核心网络层之上的跨平台客户端网络库从准备发布到发布产物再到密钥维护的完整工作流。你将掌握如何正确提交发布前置 PR版本号 版本历史、打 tag 后 CI 如何自动产出 iOS/Android 产物并发布到 Maven 与 CocoaPods、预发布版本的X.Y.Z.{yyyymmdd}命名规范以及 GPG 签名密钥的生成、导出与在 GitHub Secrets 中的轮换方法。文中所有关键环节均附当前仓库源码佐证可直接对照落地。发布前准备工作先合入版本号与版本说明正式发布cutting a release之前需要先提交并合入一个 PR其中包含两处强制变更提升 mobile/VERSION 文件中的版本号。当前仓库中该文件内容为0.5.0即最新正式版本的版本号来源也是后续所有 CI 校验、文档发布判断的依据。在版本历史文档 mobile/docs/root/intro/version_history.rst 中补充本次发布的概述。关于版本历史文档的组织方式仓库中的 mobile/RELEASE.md 给出了更细的实操约束在文件顶部新增一个Pending Release小节内含Bugfixes:与Features:等分类条目将旧的Pending Release小节改为带版本号和发布日期的形式例如0.5.0 (September 2, 2022)用git log \git rev-list --tags --max-count1..HEAD 核对自上次发布以来的所有变更是否都已写入当前发布说明若构建的是季度发布quarterly release还需在版本历史中注明所基于的 Envoy 上游 tag例如0.4.5版本标注了 Based off Envoy v1.21.0。从 mobile/docs/root/intro/version_history.rst 的既有记录可以看到每条发布说明的标准形态以版本号 日期为小节标题按Breaking changes、Bugfixes、Features分类罗列并对 API 变更给出精确的接口名与对应 issue 编号。这是评审者与下游用户判断升级影响面的第一手资料。此外根据 mobile/RELEASE.md非季度发布只需同步VERSION与版本历史季度发布还需额外确保 Envoy checkout 指向最新的 Envoy 上游发布 tag并同步EnvoyMobile.podspec中的版本号。将这些变更以 PR 形式提交、评审、合入后才进入发布环节。发布与产物发布打 tag 触发全自动流水线前置 PR 合入后即可为本次发布打 tag例如v0.5.0。打 tag 的行为会在 main 分支上自动触发一组 CI 任务完成以下四件事创建 GitHub Release并附带 iOS 与 Android 构建产物将版本发布到 Maven 与 CocoaPods 分发渠道发布最新版本的 Envoy Mobile 文档。发布物的构成与手工补充步骤尽管 CI 会自动生成发布物mobile/RELEASE.md 仍记录了发布者需要跟进的人工环节等待对应 tag 的 artifacts workflow 跑完下载envoy_android_aar_sources、envoy_ios_cocoapods、envoy_ios_framework三份产物回到已创建的 release 页面将其编辑上传挂载。文档发布的 tag 校验逻辑文档的自动化发布由 mobile/docs/build.sh 驱动其中体现了清晰的版本策略只有形如vX.Y.Z的正式发布 tag 才会发布带标签的文档DOCS_TARGET//docs且强制校验 git tag 与VERSION文件内容一致v${VERSION_NUMBER}必须等于GITHUB_REF_NAME同时要求version_history.rst中存在当前版本号形如vX.Y.Z.ddmmyy的预发布 tag 不发布带标签文档走普通//docs:html目标文档产物输出到generated/docs通过envoy//tools/tarball:unpack解包发布。这解释了为什么预发布版本虽然每周发布却不会污染正式文档站点。Maven 发布的实现细节MavenSonatype OSSRH的发布逻辑沉淀在 mobile/ci/sonatype_nexus_upload.py 中可作为理解CI 自动发布内部机制的源码参考通过READWRITE_USER/READWRITE_API_KEY环境变量做 Basic 认证目标为https://oss.sonatype.org/service/local/staging构件坐标为io.envoyproxy.envoymobile发布文件清单为envoy.aar、envoy-pom.xml、envoy-sources.jar、envoy-javadoc.jarSonatype 要求所有上传构件经 GPG 签名因此脚本支持--signed_files传入.asc签名文件如envoy.aar.asc这正是本文后半部分 GPG 密钥管理的直接业务场景上传流程遵循 Sonatype 标准 staging 生命周期创建 staging repository → 上传文件与 SHA-256 校验文件 → closefinish→ promoterelease任一环节失败会尝试 drop staging repository 并终止网络层对 5xx 错误最多重试 500 次每次间隔 1 秒注释中说明这是为了应对 Sonatype 频繁失败的实际经验支持--local模式将构件安装到本地~/.m2/repository/io/envoyproxy/envoymobile/便于发布前自测。Android AAR 产物的构建规则见 mobile/bazel/android_artifacts.bzl由于 bazelandroid_library的隐式 aar 输出不会扁平化传递依赖且 kotlin 规则会生成多层底层库导致 classes.jar 为空该宏手工组装 aar产出 aar、pom、sources.jar、javadoc.jar 四类文件与上传脚本的文件清单一一对应。预发布版本号规范周更与日期后缀预发布pre-release按周发布版本号方案为X.Y.Z.{yyyymmdd}例如 2020 年 1 月 25 日的预发布版本即为0.3.1.20200125。要点解读X.Y.Z对应当前正式版本的语义化版本号{yyyymmdd}是八位日期后缀用于在同一正式版本号下区分每周的预发布构建该后缀使预发布 tag 天然不满足 mobile/docs/build.sh 中^[0-9]\.[0-9]\.[0-9]$的正则校验从而自动跳过带标签文档的发布避免预发布污染正式文档站点当前仓库 mobile/VERSION 中的0.5.0即对应的正式版本基线。GPG 密钥签名密钥的生成与轮换流程由于 Maven Central 要求上传构件必须经过 GPG 签名见上文 mobile/ci/sonatype_nexus_upload.py 对--signed_files的说明Envoy Mobile 使用专用的 GPG 密钥对发布物签名。当密钥需要更新轮换时按以下步骤执行1. 生成新的密钥对$ gpg --full-generate-key按交互式提示完成生成算法、长度、有效期等。生成过程中会设置 PASSPHRASE务必记下该口令后续需要写入 GitHub Secrets。2. 确认密钥身份信息生成密钥时Real Name填写Envoy Release Botemail 填写noreplyenvoyproxy.io即发布机器人专用身份便于审计与辨识。3. 查看并导出私钥$ gpg --list-keys $ gpg --armor --export-secret-keys $KEY_ID先用--list-keys找到新密钥的 KEY_ID再以其导出 ASCII armored 格式的私钥即步骤 5 中用于签名/解密的密钥材料。4. 重新分发公钥$ gpg --keyserver keyserver.ubuntu.com --send-keys $KEY_ID将新公钥上传到公钥服务器如 Ubuntu keyserver使验证方能够获取公钥校验签名。5. 更新 GitHub 仓库 Secrets请 Envoy GitHub 仓库管理员更新以下两个 SecretsEM_GPG_PASSPHRASEpassphrase noted down from step 2 EM_GPG_KEYsecret key from step 5EM_GPG_PASSPHRASE步骤 2 中记录的口令EM_GPG_KEY步骤 5 导出的 ASCII armored 私钥内容。这两个 Secret 是 CI 在发布时对构件进行 GPG 签名生成.asc签名文件并上传 Sonatype的凭据来源。轮换完成后旧的密钥/口令即可废弃。结合仓库实践的发布自检清单将 mobile/docs/root/development/releasing/releasing.rst 与 mobile/RELEASE.md 合并可得到一份完整的发布执行清单阶段动作仓库依据准备更新 mobile/VERSION 版本号mobile/RELEASE.md准备在 mobile/docs/root/intro/version_history.rst 新增/更新发布说明同上0.5.0 (September 2, 2022)小节为范例准备季度发布同步 Envoy 上游 tag 与 podspec同上发布打 tag正式版vX.Y.Z触发 CI原文档 mobile/docs/build.sh发布CI 创建 GitHub Release、iOS/Android 产物、Maven/CocoaPods 发布、文档发布原文档跟进下载envoy_android_aar_sources、envoy_ios_cocoapods、envoy_ios_framework并挂载到 releasemobile/RELEASE.md密钥按 GPG 流程轮换EM_GPG_PASSPHRASE/EM_GPG_KEY原文档其中文档发布依赖 mobile/docs/build.sh 对 tag 名与 VERSION 文件的一致性校验Maven 上传依赖 mobile/ci/sonatype_nexus_upload.py 的 staging 流水线与 GPG 签名文件Android 构件由 mobile/bazel/android_artifacts.bzl 手工组装 aar。发布者只要按表推进即可在 CI 自动化与人工核对之间形成闭环保证每个版本从代码合入到终端用户可下载的完整链路可追溯、可复现。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考