拓冰网站定制 
legacy-rocm-build autotag一个 300 行脚本如何给 40 个 GPU 库自动打 tag 并生成发布说明【免费下载链接】legacy-rocm-buildAMD ROCm™ Software - GitHub Home项目地址: https://gitcode.com/GitHub_Trending/ro/legacy-rocm-buildROCm 的一次发版锚定在同一个日期上却散布在 40 多个彼此独立的 GitHub 仓库里MIOpen、hipBLAS、rccl、llvm-project……每个仓库的发布 commit 各不相同没有任何统一版本库能回答这个 ROCm 版本下某库的哪个 commit 算数。legacy-rocm-build autotag 模块用约 300 行 Pythontools/autotag/tag_script.py加一个 XML 清单、一个 Jinja2 模板回答这个问题。读完你会拿到一套可复用的多仓库发布流水线骨架——清单即唯一数据源、tag 即版本锚点、正则解析CHANGELOG.md、模板拼装 release notes——以及它必然失效的四处位置。为什么难40 仓库、1 个发布日、0 个统一版本库约束逐条列出每条决定一类设计版本锚点分散同一 ROCm 版本下各库的发布 commit 只存在于各自仓库的rocm-X.Y.Ztag 里且个别库发版时间滞后。所以设计必须把tag 查询作为版本定位的唯一事实来源而不是信任任何中央数据库。token 不可靠发布日运行脚本的人未必有 GitHub token匿名读 API 还会撞 rate limit。所以设计必须让版本信息走一条不需要认证的通道token 只在写操作建 tag、提 PR时才必需。changelog 是人写的每个库的CHANGELOG.md头部格式不完全一致HIPIFY的标题甚至不带库版本号。所以设计必须给一个默认解析正则同时留按库覆盖的挂点解析失败时降级成交互确认而不是崩溃。release notes 是机器生成与人工撰写的混合体组件表由脚本生成但 highlights、known issues 等段落由人按版本维护。所以设计必须让缺失的人工文件被静默跳过而不是打断整个流水线。打 tag 和提 PR 不可逆所以设计必须对每个仓库逐一确认并提供批量模式下用标志位强制跳过的开关。设计全景从约束到源码的四行地图约束设计决策源码落点版本锚点分散tag 优先定位 commit仅最新版本允许 fallback 到 release 分支头tools/autotag/util/release_data.py#L386-L399匿名读、限流敏感用git ls-remote --tags拉版本表不消耗 API 配额tools/autotag/util/release_data.py#L349-L364changelog 格式不一默认正则 defaultdict挂点按库覆盖tools/autotag/util/defaults.py#L10-L19、tools/autotag/util/custom_templates/hipify.py#L6-L15机器/人工内容混杂Jinjainclude ... ignore missing静默跳过缺失段落tools/autotag/templates/changelog.jinja#L13-L21操作不可逆--do-X/--no-X标志对 交互式 y/n 双闸门tools/autotag/tag_script.py#L96-L119、tools/autotag/util/util.py#L7-L17用git ls-remote换 API 调用是多仓库发布脚本里典型的用一次网络往返换零认证零限流读版本信息只依赖 tag 命名规范本身。版本锚点tag 优先、分支兜底且只允许最新版本无 tag机制分两级。入口create_data_dict先对 ROCm 主仓执行fetch_tags拿到全部已发版号再遍历[min_version, up_to_version]逐个版本建 bundlerelease_data.py#L430-L455。对每个库get_tag查该版本对应 tag 的 commit查不到时只有is_untaggedTrue即目标版本等于最大版本才降级取--branch release/rocm-rel-X.Y分支头 commit 顶替分支也不存在则记入missing_branches并跳过该库release_data.py#L386-L399。tag 的解析规则集中在fetch_tags正则rocm-(\d(\.\d))抓取 tag 名再把6.4这类两段版本号补零成6.4.0再比对rocm_ver .0 * (2 - rocm_ver.count(.))release_data.py#L357-L363。同一个补零逻辑也决定发布时的 tag 名——ReleaseLib.full_version与tag属性rocm-{full_version}release_data.py#L55-L67保证rocm-6.4.3与rocm-6.4都能被定位。代价与边界历史版本无 tag 即跳过意味着某个库漏打 tag 时release notes 里对应行会静默消失脚本不报错——这是用发布说明可能缺行换流水线永不因历史数据中断。而最新版本允许无 tag是因为发版窗口内 release 分支可能还在滚动代价是最新版本号解析 changelog 时必须容忍未标注 ROCm 版本的段落触发 defaults.py#L43-L47 的交互确认。解析人写的 CHANGELOG.md默认正则就是一份契约机制default_processor用认证 API 拉取发布 commit 处的CHANGELOG.mddata.repo.get_contents(CHANGELOG.md, data.commit)defaults.py#L29-L30用template_factory()的大正则逐段匹配## 库名 版本 [for ROCm X.Y]形式的章节头再按 ROCm 版本做过滤高于当前版跳过、低于当前版的记为latest_match最后用第二个正则把章节体按# 小标题切成data.changes字典供模板渲染defaults.py#L60-L67。一条库的自定义解析器只需向TEMPLATES/PROCESSORS两个defaultdict注册即可——HIPIFY就是范例它的章节头没有库版本号正则直接取for ROCm后的版本当lib_versionhipify.py#L6-L40。整篇 changelog 都匹配不到时的兜底分两支若该 commit 已有任何 tagis_previous说明库代码没变、只是为新版 ROCm 重建脚本自动生成code did not change, rebuilt样板文案否则交互询问无变更也发吗答否则该库计入faileddefaults.py#L69-L91。代价与边界正则即契约。库名只接受[a-zA-Z-]版本号形如2.1.0-1可以、2.1.0local不行。格式偏移不会报错只会让匹配静默落空、降级进无变更分支——二次开发时最容易在这里被坑验证方式见下节。说明拼装机器写表格人写正文缺文件静默跳过机制Changelog构造时建两个索引——rocm_ver_by_lib_ver每个库版本首次出现的 ROCm 版号和prev_lib_ver每个版本的前驱版本逻辑见 changelog.py#L21-L43。jinja 模板按版本渲染三部分先是组件表行级去重条件是该库版本本版本首次出现且存在前驱版本满足则渲染旧版本 ⇒ 新版本箭头行否则只渲染单个版本链接changelog.jinja#L41-L60再是每库的变更章节同样受同一去重条件约束changelog.jinja#L65-L78最后按版本名 includehighlights/、support/、extra_components/、known_issues/、resolved_issues/、upcoming_changes/六个手写段落目录全部ignore missingchangelog.jinja#L13-L21、L80-L90。仓库内现成证据tools/autotag/templates/highlights/6.3.0.md 等手写模板覆盖 5.0.0 至 6.3.3 共 28 个版本与known_issues/、resolved_issues/的按版本文件一一对应正是这个 include 机制的消费端。代价与边界版本未变 不渲染 changelog 章节是隐式契约——某库版本不变时读者看不到它为何重建的解释手写模板忘了写则整段静默为空。权衡在于release notes 管线永远不会因为某个人忘了写文件而断但代价也没人能发现那个文件缺失。实战走查 干跑一次 6.4.3 的 release notes 编译完整流水线是七步解析参数 → 加载 components.xml默认./components.xml可用--manifest-url换成远端快照tag_script.py#L190-L198→ 按category过滤只保留libs/tools/compilers/runtimes四类tag_script.py#L238-L247→ 逐版本建 bundle → 逐库解析 changelog → 编译 notes → 可选的 tag 与 PR。关键 I/O 通道对比操作通道认证拉各库 tag 列表git ls-remote --tags无需读指定 commit 的CHANGELOG.mdGitHub APIget_contents需要 token建 tag / 发 releaseGitHub API需要 token提 hotfix 回流 PRbot fork 推送ROCmMathLibrariesBot需要 PR token干跑示例不建 tag、不提 PR只出 notes可直挂 CI 门禁git clone https://gitcode.com/GitHub_Trending/ro/legacy-rocm-build cd legacy-rocm-build/tools/autotag pip install -r requirements.txt python3 tag_script.py \ --no-release --no-pulls \ --starting-version 6.0.0 \ --branch release/rocm-rel-6.4.3 \ 6.4.3 --compile_file .changelogs.md错误分支任一库解析失败会被收集进failed列表结束时逐条打印到 stderr 并sys.exit(1)tag_script.py#L308-L312因此上一条命令的退出码可直接当门禁用。验证 changelog 正则契约不需要网络和 token本地 20 行即可import re from util.defaults import template_factory # 在 tools/autotag 下运行 pattern re.compile(template_factory()) changelog open(CHANGELOG.md, encodingutf-8).read() matches list(pattern.finditer(changelog)) if not matches: raise SystemExit(无章节匹配检查 ## 头部格式是否符合默认正则) first matches[0] print(f最新段: {first[lib_name]} {first[lib_version]} f (ROCm {first[rocm_version] or 未标注}))把某库真实CHANGELOG.md喂进去lib_version解析为空或rocm_version全为未标注就是在提前复现静默降级那条失败路径。另有一处漂移需要提醒官方包装脚本 compile_changelogs.sh#L8 传了--no-previous并把输出文件当位置参数但当前解析器只注册了--compile_filetag_script.py#L171-L176且没有previous参数对——直接跑该 shell 脚本会 argparse 报错。shell 包装器已 bit-rot以tag_script.py直接调用为准。失败模式与边界 ⚠️它会在哪里断失败场景现象设计行为无 tokenValueError→ 交互匿名继续tag_script.py#L200-L213匿名可读高频调用有 rate limit 风险非最新版本缺 tag该库从 bundle 中消失静默跳过notes 缺行最新版本缺 tag 且缺分支missing_branches打印不影响退出码changelog 解析失败且确认有变更计入failedstderr 列表 exit 1仓库已发过版create_git_tag_and_release抛异常吞掉并打印Already releasedrelease_data.py#L130-L131幂等靠异常org/user 不存在ValueError直接崩溃明确不做什么不校验 tag 指向的 commit 真属于 release 分支信任 tag 本身不给libs/tools/compilers/runtimes之外的 category 建 bundle不检查跨库版本一致性hotfix 回流 PR 的 fork 目标硬编码为ROCmMathLibrariesBotrelease_data.py#L150-L152换组织必须改代码。验收清单干跑退出码为 0failed列表为空.changelogs.md中每行组件版本都能对应到一次真实的rocm-X.Y.Ztag抽查一个版本未变的库确认它只出现在组件表而不带 changelog 章节契约行为而非 bug;故意喂一份格式偏移的CHANGELOG.md给本地正则示例确认它走进无章节匹配分支而不是产生错误版本号;二次开发新增自定义解析器后确认默认库的行为未被defaultdict挂点改动。总结legacy-rocm-build autotag 用tag 即锚点、正则即契约、缺失即跳过、确认即闸门四个决定把多仓库发版从手工操作压成一条退出码可验证的管线。它的可靠性上限由rocm-X.Y.Ztag 命名规范和 changelog 头部格式这两个人守约定决定。【免费下载链接】legacy-rocm-buildAMD ROCm™ Software - GitHub Home项目地址: https://gitcode.com/GitHub_Trending/ro/legacy-rocm-build创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 legacy-rocm-build autotag：一个 300 行脚本如何给 40+ 个 GPU 库自动打 tag 并生成发布说明
legacy-rocm-build autotag一个 300 行脚本如何给 40 个 GPU 库自动打 tag 并生成发布说明【免费下载链接】legacy-rocm-buildAMD ROCm™ Software - GitHub Home项目地址: https://gitcode.com/GitHub_Trending/ro/legacy-rocm-buildROCm 的一次发版锚定在同一个日期上却散布在 40 多个彼此独立的 GitHub 仓库里MIOpen、hipBLAS、rccl、llvm-project……每个仓库的发布 commit 各不相同没有任何统一版本库能回答这个 ROCm 版本下某库的哪个 commit 算数。legacy-rocm-build autotag 模块用约 300 行 Pythontools/autotag/tag_script.py加一个 XML 清单、一个 Jinja2 模板回答这个问题。读完你会拿到一套可复用的多仓库发布流水线骨架——清单即唯一数据源、tag 即版本锚点、正则解析CHANGELOG.md、模板拼装 release notes——以及它必然失效的四处位置。为什么难40 仓库、1 个发布日、0 个统一版本库约束逐条列出每条决定一类设计版本锚点分散同一 ROCm 版本下各库的发布 commit 只存在于各自仓库的rocm-X.Y.Ztag 里且个别库发版时间滞后。所以设计必须把tag 查询作为版本定位的唯一事实来源而不是信任任何中央数据库。token 不可靠发布日运行脚本的人未必有 GitHub token匿名读 API 还会撞 rate limit。所以设计必须让版本信息走一条不需要认证的通道token 只在写操作建 tag、提 PR时才必需。changelog 是人写的每个库的CHANGELOG.md头部格式不完全一致HIPIFY的标题甚至不带库版本号。所以设计必须给一个默认解析正则同时留按库覆盖的挂点解析失败时降级成交互确认而不是崩溃。release notes 是机器生成与人工撰写的混合体组件表由脚本生成但 highlights、known issues 等段落由人按版本维护。所以设计必须让缺失的人工文件被静默跳过而不是打断整个流水线。打 tag 和提 PR 不可逆所以设计必须对每个仓库逐一确认并提供批量模式下用标志位强制跳过的开关。设计全景从约束到源码的四行地图约束设计决策源码落点版本锚点分散tag 优先定位 commit仅最新版本允许 fallback 到 release 分支头tools/autotag/util/release_data.py#L386-L399匿名读、限流敏感用git ls-remote --tags拉版本表不消耗 API 配额tools/autotag/util/release_data.py#L349-L364changelog 格式不一默认正则 defaultdict挂点按库覆盖tools/autotag/util/defaults.py#L10-L19、tools/autotag/util/custom_templates/hipify.py#L6-L15机器/人工内容混杂Jinjainclude ... ignore missing静默跳过缺失段落tools/autotag/templates/changelog.jinja#L13-L21操作不可逆--do-X/--no-X标志对 交互式 y/n 双闸门tools/autotag/tag_script.py#L96-L119、tools/autotag/util/util.py#L7-L17用git ls-remote换 API 调用是多仓库发布脚本里典型的用一次网络往返换零认证零限流读版本信息只依赖 tag 命名规范本身。版本锚点tag 优先、分支兜底且只允许最新版本无 tag机制分两级。入口create_data_dict先对 ROCm 主仓执行fetch_tags拿到全部已发版号再遍历[min_version, up_to_version]逐个版本建 bundlerelease_data.py#L430-L455。对每个库get_tag查该版本对应 tag 的 commit查不到时只有is_untaggedTrue即目标版本等于最大版本才降级取--branch release/rocm-rel-X.Y分支头 commit 顶替分支也不存在则记入missing_branches并跳过该库release_data.py#L386-L399。tag 的解析规则集中在fetch_tags正则rocm-(\d(\.\d))抓取 tag 名再把6.4这类两段版本号补零成6.4.0再比对rocm_ver .0 * (2 - rocm_ver.count(.))release_data.py#L357-L363。同一个补零逻辑也决定发布时的 tag 名——ReleaseLib.full_version与tag属性rocm-{full_version}release_data.py#L55-L67保证rocm-6.4.3与rocm-6.4都能被定位。代价与边界历史版本无 tag 即跳过意味着某个库漏打 tag 时release notes 里对应行会静默消失脚本不报错——这是用发布说明可能缺行换流水线永不因历史数据中断。而最新版本允许无 tag是因为发版窗口内 release 分支可能还在滚动代价是最新版本号解析 changelog 时必须容忍未标注 ROCm 版本的段落触发 defaults.py#L43-L47 的交互确认。解析人写的 CHANGELOG.md默认正则就是一份契约机制default_processor用认证 API 拉取发布 commit 处的CHANGELOG.mddata.repo.get_contents(CHANGELOG.md, data.commit)defaults.py#L29-L30用template_factory()的大正则逐段匹配## 库名 版本 [for ROCm X.Y]形式的章节头再按 ROCm 版本做过滤高于当前版跳过、低于当前版的记为latest_match最后用第二个正则把章节体按# 小标题切成data.changes字典供模板渲染defaults.py#L60-L67。一条库的自定义解析器只需向TEMPLATES/PROCESSORS两个defaultdict注册即可——HIPIFY就是范例它的章节头没有库版本号正则直接取for ROCm后的版本当lib_versionhipify.py#L6-L40。整篇 changelog 都匹配不到时的兜底分两支若该 commit 已有任何 tagis_previous说明库代码没变、只是为新版 ROCm 重建脚本自动生成code did not change, rebuilt样板文案否则交互询问无变更也发吗答否则该库计入faileddefaults.py#L69-L91。代价与边界正则即契约。库名只接受[a-zA-Z-]版本号形如2.1.0-1可以、2.1.0local不行。格式偏移不会报错只会让匹配静默落空、降级进无变更分支——二次开发时最容易在这里被坑验证方式见下节。说明拼装机器写表格人写正文缺文件静默跳过机制Changelog构造时建两个索引——rocm_ver_by_lib_ver每个库版本首次出现的 ROCm 版号和prev_lib_ver每个版本的前驱版本逻辑见 changelog.py#L21-L43。jinja 模板按版本渲染三部分先是组件表行级去重条件是该库版本本版本首次出现且存在前驱版本满足则渲染旧版本 ⇒ 新版本箭头行否则只渲染单个版本链接changelog.jinja#L41-L60再是每库的变更章节同样受同一去重条件约束changelog.jinja#L65-L78最后按版本名 includehighlights/、support/、extra_components/、known_issues/、resolved_issues/、upcoming_changes/六个手写段落目录全部ignore missingchangelog.jinja#L13-L21、L80-L90。仓库内现成证据tools/autotag/templates/highlights/6.3.0.md 等手写模板覆盖 5.0.0 至 6.3.3 共 28 个版本与known_issues/、resolved_issues/的按版本文件一一对应正是这个 include 机制的消费端。代价与边界版本未变 不渲染 changelog 章节是隐式契约——某库版本不变时读者看不到它为何重建的解释手写模板忘了写则整段静默为空。权衡在于release notes 管线永远不会因为某个人忘了写文件而断但代价也没人能发现那个文件缺失。实战走查 干跑一次 6.4.3 的 release notes 编译完整流水线是七步解析参数 → 加载 components.xml默认./components.xml可用--manifest-url换成远端快照tag_script.py#L190-L198→ 按category过滤只保留libs/tools/compilers/runtimes四类tag_script.py#L238-L247→ 逐版本建 bundle → 逐库解析 changelog → 编译 notes → 可选的 tag 与 PR。关键 I/O 通道对比操作通道认证拉各库 tag 列表git ls-remote --tags无需读指定 commit 的CHANGELOG.mdGitHub APIget_contents需要 token建 tag / 发 releaseGitHub API需要 token提 hotfix 回流 PRbot fork 推送ROCmMathLibrariesBot需要 PR token干跑示例不建 tag、不提 PR只出 notes可直挂 CI 门禁git clone https://gitcode.com/GitHub_Trending/ro/legacy-rocm-build cd legacy-rocm-build/tools/autotag pip install -r requirements.txt python3 tag_script.py \ --no-release --no-pulls \ --starting-version 6.0.0 \ --branch release/rocm-rel-6.4.3 \ 6.4.3 --compile_file .changelogs.md错误分支任一库解析失败会被收集进failed列表结束时逐条打印到 stderr 并sys.exit(1)tag_script.py#L308-L312因此上一条命令的退出码可直接当门禁用。验证 changelog 正则契约不需要网络和 token本地 20 行即可import re from util.defaults import template_factory # 在 tools/autotag 下运行 pattern re.compile(template_factory()) changelog open(CHANGELOG.md, encodingutf-8).read() matches list(pattern.finditer(changelog)) if not matches: raise SystemExit(无章节匹配检查 ## 头部格式是否符合默认正则) first matches[0] print(f最新段: {first[lib_name]} {first[lib_version]} f (ROCm {first[rocm_version] or 未标注}))把某库真实CHANGELOG.md喂进去lib_version解析为空或rocm_version全为未标注就是在提前复现静默降级那条失败路径。另有一处漂移需要提醒官方包装脚本 compile_changelogs.sh#L8 传了--no-previous并把输出文件当位置参数但当前解析器只注册了--compile_filetag_script.py#L171-L176且没有previous参数对——直接跑该 shell 脚本会 argparse 报错。shell 包装器已 bit-rot以tag_script.py直接调用为准。失败模式与边界 ⚠️它会在哪里断失败场景现象设计行为无 tokenValueError→ 交互匿名继续tag_script.py#L200-L213匿名可读高频调用有 rate limit 风险非最新版本缺 tag该库从 bundle 中消失静默跳过notes 缺行最新版本缺 tag 且缺分支missing_branches打印不影响退出码changelog 解析失败且确认有变更计入failedstderr 列表 exit 1仓库已发过版create_git_tag_and_release抛异常吞掉并打印Already releasedrelease_data.py#L130-L131幂等靠异常org/user 不存在ValueError直接崩溃明确不做什么不校验 tag 指向的 commit 真属于 release 分支信任 tag 本身不给libs/tools/compilers/runtimes之外的 category 建 bundle不检查跨库版本一致性hotfix 回流 PR 的 fork 目标硬编码为ROCmMathLibrariesBotrelease_data.py#L150-L152换组织必须改代码。验收清单干跑退出码为 0failed列表为空.changelogs.md中每行组件版本都能对应到一次真实的rocm-X.Y.Ztag抽查一个版本未变的库确认它只出现在组件表而不带 changelog 章节契约行为而非 bug;故意喂一份格式偏移的CHANGELOG.md给本地正则示例确认它走进无章节匹配分支而不是产生错误版本号;二次开发新增自定义解析器后确认默认库的行为未被defaultdict挂点改动。总结legacy-rocm-build autotag 用tag 即锚点、正则即契约、缺失即跳过、确认即闸门四个决定把多仓库发版从手工操作压成一条退出码可验证的管线。它的可靠性上限由rocm-X.Y.Ztag 命名规范和 changelog 头部格式这两个人守约定决定。【免费下载链接】legacy-rocm-buildAMD ROCm™ Software - GitHub Home项目地址: https://gitcode.com/GitHub_Trending/ro/legacy-rocm-build创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考