librdkafka NuGet 打包发布实战从 CI 产物到 librdkafka.redist.nupkg 的完整流水线【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit本文以 librdkafka 仓库当前以子模块形式内嵌于 fluent-bit 项目的lib/librdkafka-2.15.0中自带的 NuGet 打包与发布流程文档为骨架系统讲解如何将跨平台 CI 构建产物收集、组装、验证并发布为 NuGet 包与静态库 bundle。读完本文你将掌握release.py的全部命令行用法、S3 产物命名规则、NugetPackage/StaticPackage两种打包类的工作原理以及如何安全地清理 CI 产物桶。一、这套打包体系要解决什么问题librdkafka 是 Apache Kafka 的 C/C 客户端库它需要同时为 Linuxglibc 与 musl、macOSx64/arm64、Windowsx86/x64等多个平台、多种架构产出二进制。单个平台由各自的 CI 系统Travis、AppVeyor、SemaphoreCI 等构建产物散落在 S3 桶或本地目录中。lib/librdkafka-2.15.0/packaging/nuget/README.md描述的正是这套聚合式打包体系一组 Python 脚本从本地目录或 S3 收集 CI 产物在一个 staging暂存目录中按打包类packaging class定义的包结构重新组装。其中NugetPackage类在 staging 目录之上通过 Docker 内运行的 NuGet 工具生成带完整元数据的 NuGet 包StaticPackage类将各平台的静态库打包成一个自包含的 tarball最终的 NuGet 包可以手工上传到 NuGet.org也可以让脚本自动上传。换句话说这套脚本是多平台 CI 二进制分发的最后一公里把散落在不同构建系统的碎片合并成一个开发者可以dotnet add package librdkafka.redist直接消费的交付物。二、运行环境要求原文档明确给出了三个前置条件位于 packaging/nuget/README.mdPython 3全部打包脚本均为 Python 3 编写DockerNuGet 工具本身在 Docker 容器内运行详见下文nuget.sh上传也依赖 Docker可选私有 S3 访问密钥仅当使用--s3从librdkafka-ci-packages桶收集产物时才需要。依赖清单见 packaging/nuget/requirements.txtboto3~1.38 rpmfile~1.1 filemagic~1.6boto3访问 S3 桶rpmfile解析 RPM 相关文件filemagiclibmagic的 Python 绑定用于校验下载的二进制文件类型与声明的平台/架构是否一致见下文产物真实性校验。三、完整发布流程原文七步走原文档给出了从打标签到上传 NuGet 的完整操作路径逐条继承如下。第 1 步触发 CI 构建在 librdkafka 仓库中创建并推送一个 release或 release candidate标签确保标签打在正确的分支上$ git tag v0.11.0-RC3 $ git push origin v0.11.0-RC3第 2 步等待 CI 构建完成各平台 CI 构建完成后产物会上传到 S3。原文档提供了监控入口SemaphoreCI 的 librdkafka 项目新构建、Travis 与 AppVeyor历史构建。若使用 SemaphoreCI也可以让打包 job 直接依赖同一流水线中的前置构建 job从而免去人工等待。第 3 步运行 release.py 组装 NuGet 包在 Linux 主机上进入packaging/nuget目录执行$ cd packaging/nuget # 指定标签 $ ./release.py v0.11.0-RC3 # 若标签被移动过、需要同时精确匹配某个 git sha # $ ./release.py --sha the-full-git-sha v0.11.0-RC3第 4 步产物齐全后生成 nupkg如果所有产物均已就绪NuGet 包会被构建并输出到当前目录命名为librdkafka.redist.去 v 前缀的标签.nupkg例如librdkafka.redist.0.11.0-RC3.nupkg。第 5 步手动测试包将 nupkg 安装到实际项目中验证链接、运行、依赖如 Windows 下的 VC 运行库均正常。第 6 步上传 NuGet手工上传至 NuGet.org 的包管理页。第 7 步可选自动上传若已信任整个流程可以让release.py构建后自动上传$ ./release.py --retries 100 --upload your-nuget-api.key v0.11.0-RC3四、release.py 命令行参数全解原文档只展示了部分用法结合 packaging/nuget/release.py 的argparse定义完整参数如下参数说明默认值tag位置参数要收集产物的 git 标签必填--s3从 S3 桶收集产物否则只从本地目录收集关闭--dry-run只定位产物不实际下载、不构建任何东西关闭--directory dir下载目录也用于收集本地已有产物dl-tag--no-cleanup构建完成后保留临时目录staging 目录关闭--sha sha1额外按 git sha1 精确匹配产物无--ignore-tag忽略产物中的 tag 属性仅开发用关闭--nuget-version ver指定 NuGet 包版本默认与标签同名标签名--upload key或文件构建后自动上传值为 NuGet API key 或存放 key 的文件路径无--class 类名打包类NugetPackage或StaticPackageNugetPackage--retries n收集产物缺失时的重试次数配合--s3每次间隔 30 秒0几个值得注意的实现细节匹配逻辑release.py先根据--sha/--ignore-tag构造match字典默认{tag: 标签}再叠加所选打包类自带的match属性Artifacts对象用这个字典过滤 S3 中的对象见 packaging.py 的collect_single。重试机制构建过程中若抛出MissingArtifactError且指定了--retries脚本打印错误、清理临时目录、等待 30 秒后重试release.py的 while 循环适合 S3 上传有延迟的场景。key 的两种形式--upload若指向一个已存在的文件则读取文件内容并去除换行作为 API key否则把参数值本身当作 key。上传失败即失败上传通过./push-to-nuget.sh执行退出码非 0 时断言失败并给出错误信息。五、S3 产物命名规范token 编码收集产物时脚本依赖 S3 对象路径中编码的token来完成匹配。规范格式见 packaging.py 的类注释与collect_single的正则token-[value]__ 可重复识别的 token 及含义Token含义示例值p项目librdkafka、confluent-kafka-pythonbld构建系统travis、appveyor、semaphoreplat平台osx、linux、windist发行版/运行时centos8、mingw、msvcr、alpinearch架构x64、x86、arm64、s390xtaggit 标签v0.11.0-RC3shagit sha完整 40 位 shabid构建 ID1562.1bldtype构建类型Release、Debuglnk链接方式std动态、static、all两者都含extra附加选项gssapicyrus-sasl 链接真实路径示例librdkafka/p-librdkafka__bld-travis__plat-linux__arch-x64__tag-v0.0.62__sha-d051b2c19eb0c118991cd8bc5cf86d8e5e446cde__bid-1562.1/librdkafka.tar.gz脚本会做以下归一化与过滤均在packaging.py中实现值重命名rename_vals将windows→win、x86_64/amd64→x64、i386/win32→x86统一 token 取值忽略 Debug 产物bldtypedebug的 AppVeyor 产物被直接丢弃处理未展开的 AppVeyor tokenAppVeyor 在未设置标签时会把$(APPVEYOR_REPO_TAG_NAME)原样留在路径里脚本识别并删除该 token符号包降权文件名含.symbols.的产物 score 减 10在排序中靠后Artifact.__init__common 产物豁免pcommon的通用产物如 VC 运行库 zip不要求 tag 匹配。产物真实性校验filemagic收集到的二进制会按(plat, arch, 扩展名)查表做文件类型校验magic_patterns例如Windows x64 的.dll必须匹配PE32.*DLL.* x86-64, for MS WindowsLinux x64 的.so必须匹配ELF 64.* x86-64macOS x64 的.dylib必须匹配Mach-O 64.* x86_64。校验失败会打印 Warning并且该文件不会被纳入包内apply_mappings中magic_mismatch为真时删除输出文件后继续。这是一道防止架构标错的自动化防线。六、NugetPackage 打包类staging 目录组装原理NugetPackage 类 把所有平台、架构的产物合并进一套 NuGet 输出。其build()流程如下创建临时 staging 目录out-*前缀渲染templates/librdkafka.redist.nuspec模板版本号代入${version}复制librdkafka.redist.targets到build/native/、librdkafka.redist.props到build/为每个产物补充variant形如linux-x64-release与toolset默认v142字段调用apply_mappings()按映射表抽取归档内文件到目标路径调用./nuget.sh pack nuspec路径 -BasePath staging -NonInteractive生成 nupkg版本号自动去掉前缀v。6.1 映射表产物文件 → 包内路径mappings是一个Mapping对象列表每个映射声明匹配哪些产物属性attributes、匹配哪种文件名artifact_fname_glob、从归档中抽取哪个文件path_in_artifact、放到包内哪个路径output_pkg_path缺省与源路径相同。属性键以!开头表示必须不匹配。关键映射示例nugetpackage.py头文件Linux x64std链接的librdkafka.tgz中的rdkafka.h、rdkafkacpp.h、rdkafka_mock.h→build/native/include/librdkafka/文档README.md、CONFIGURATION.md、LICENSES.txt→ 包根目录运行时动态库runtimes/rid/native/对应 .NET 的 Runtime IdentifiermacOS x64librdkafka.dylib→runtimes/osx-x64/native/macOS arm64librdkafka.1.dylib→runtimes/osx-arm64/native/Linux glibccentos8x64librdkafka.so.1→runtimes/linux-x64/native/librdkafka.so另有无 GSSAPI 依赖的centos8-librdkafka.so变体Linux glibc arm64/s390x、Linux muslalpinex64/arm64各自的librdkafka.so变体Windows x64/x86librdkafka.dll、librdkafkacpp.dll、OpenSSLlibcrypto-3-*.dll、libssl-3-*.dll、z.dll、zstd.dll、libcurl.dll以及从common目录抽取的vcruntime140.dll、msvcp140.dllVC 运行库Windows 链接库.liblibrdkafka.lib、librdkafkacpp.lib→build/native/lib/win/x64|/x86/win-x64|win-x86-Release/v142/。6.2 nuspec 模板与 MSBuild 集成templates/librdkafka.redist.nuspec定义了包元数据ID 为librdkafka.redist、标题 librdkafka - redistributable、filesfile src** //files打包整个 staging 目录。注意 nuspec 中的${version}是由Package.render()用string.Template替换的见 packaging.py 的render方法。templates/librdkafka.redist.targets则负责消费侧自动集成当 .NET 项目引用该包时MSBuild 会自动按$(Platform)是否为x64附加对应的librdkafka.lib到AdditionalDependencies并设置AdditionalLibraryDirectories把头文件目录加入AdditionalIncludeDirectories通过ReferenceCopyLocalPaths把runtimes/win-x64/native/*.dll或 x86拷贝到输出目录。也就是说NuGet 消费者拿到的不只是二进制还有一整套即装即用的构建集成。6.3 nuget.shDocker 内的 NuGet 工具nuget.sh 是 NuGet 工具的前端封装若已在 Docker 容器内存在/.dockerenv则直接调用宿主nuget否则用mono:latest镜像挂载当前目录运行docker run -v $(pwd):/io mono:latest /io/$0 $*这解释了 README 中NuGet tool is then run (from within docker)的含义——打包主机不需要安装 .NET/mono只需有 Docker。七、StaticPackage自包含静态库 bundle除了 NuGet--class StaticPackage可生成一个 librdkafka 自包含静态库的 tarball$ ./release.py --class StaticPackage v1.1.0输出文件名为librdkafka-static-bundle-版本.tgz。根据 staticpackage.py 的注释这些静态库后续会被导入 confluent-kafka-go 使用。其映射表有两个显著特征排除 GSSAPI绝大多数映射带!extra: gssapi负向匹配因为 cyrus-sasl 是动态链接会破坏自包含例外是 macOScyrus-sasl 始终可用与 Windows从不链接。重命名产物静态库按运行时 平台重命名例如librdkafka_glibc_linux_amd64.a/librdkafka_glibc_linux_arm64.a/librdkafka_glibc_linux_s390x.acentos8librdkafka_musl_linux_amd64.a/librdkafka_musl_linux_arm64.aalpinelibrdkafka_darwin_amd64.a/librdkafka_darwin_arm64.alibrdkafka_windows.amingw每个.a还配套对应的rdkafka-static.pcpkg-config 文件重命名为librdkafka_*.pc。构建流程与 NuGet 类似创建 staging 目录 →apply_mappings()抽取文件 →tar cvzf打包build()中的subprocess.check_call。八、S3 桶清理cleanup-s3.py长期运行 CI 会在 S3 桶里积累大量非发布产物cleanup-s3.py 负责清理# 先检查只列出不删除 $ AWS_PROFILE.. ./cleanup-s3.py --age 360 # 确认无误后真正删除 $ AWS_PROFILE.. ./cleanup-s3.py --age 360 --delete--age 天只处理最后修改时间早于 N 天的对象默认 360 天判定可删除的标准may_delete路径中没有 tag或 tag 不匹配^v?\d\.\d\.\d(-?RC\d)?$即非正式 release / 非 RC 标签同时沿用与packaging.py相同的 token 解析逻辑包括处理 AppVeyor 未展开的$(token删除按每次最多 1000 个对象分块调用 S3 的delete_objectsS3 API 上限任一错误即抛异常中止未加--delete时默认是 dry-run只打印Eligible for deletion清单避免误删。九、发布后的验证与上传实现verify() 校验无论是 NugetPackage 还是 StaticPackage构建完成后release.py都会调用所选打包类的verify()继承自 packaging.py 的Package.verify以只读方式打开输出包nupkg 本质是 zip把 zip 内的文件名做 URL 解码后与所有 mapping 的output_path逐一比对缺失任何一个即校验失败并以退出码 1 终止。校验通过会打印OK - N expected files found。push-to-nuget.sh 上传push-to-nuget.sh 通过 Docker 运行 .NET SDK 完成上传docker run -t -v $PWD/$pkg:/$pkg mcr.microsoft.com/dotnet/sdk:3.1 \ dotnet nuget push /$pkg -n -s https://api.nuget.org/v3/index.json \ -k $key --source https://api.nuget.org/v3/index.json-n表示非交互-k传入 API key。手工上传则走 NuGet.org 的网页管理入口。注意本文不展开外部站点细节按原文档步骤执行即可。十、在 fluent-bit 仓库中的定位与扩展阅读在当前的 fluent-bit 仓库中librdkafka 以整棵源码树内嵌于 lib/librdkafka-2.15.0供out_kafka输出插件使用参见 plugins/out_kafka而本文介绍的打包脚本位于 lib/librdkafka-2.15.0/packaging/nuget属于 librdkafka 自身的发布工程链与 fluent-bit 的构建见 CMakeLists.txt相互独立——fluent-bit 直接以源码/子模块方式编译链接 librdkafka而非消费 NuGet 包。若希望进一步研究建议按以下顺序阅读packaging/nuget/README.md流程总览本文主体packaging/nuget/release.pyCLI 入口与重试/上传编排packaging/nuget/packaging.pyArtifact/Artifacts/Mapping/Package 四大核心类packaging/nuget/nugetpackage.py 与 packaging/nuget/staticpackage.py两种打包类的完整映射表packaging/nuget/templatesnuspec、props、targets 三个集成模板。小结这套packaging/nuget脚本把 librdkafka 的多平台 CI 产物收敛为两种可分发交付物面向 .NET 生态的librdkafka.redist.版本.nupkg含头文件、各 RID 的运行时库、MSBuild 自动集成以及面向 confluent-kafka-go 等项目的自包含静态库 tarball。其核心设计——token 化命名约定、映射表驱动的 staging 组装、filemagic 类型校验、构建后 verify 自检——对于任何需要多平台二进制聚合分发的 C/C 项目都具有直接的可借鉴价值。【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 librdkafka NuGet 打包发布实战：从 CI 产物到 librdkafka.redist.nupkg 的完整流水线
librdkafka NuGet 打包发布实战从 CI 产物到 librdkafka.redist.nupkg 的完整流水线【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit本文以 librdkafka 仓库当前以子模块形式内嵌于 fluent-bit 项目的lib/librdkafka-2.15.0中自带的 NuGet 打包与发布流程文档为骨架系统讲解如何将跨平台 CI 构建产物收集、组装、验证并发布为 NuGet 包与静态库 bundle。读完本文你将掌握release.py的全部命令行用法、S3 产物命名规则、NugetPackage/StaticPackage两种打包类的工作原理以及如何安全地清理 CI 产物桶。一、这套打包体系要解决什么问题librdkafka 是 Apache Kafka 的 C/C 客户端库它需要同时为 Linuxglibc 与 musl、macOSx64/arm64、Windowsx86/x64等多个平台、多种架构产出二进制。单个平台由各自的 CI 系统Travis、AppVeyor、SemaphoreCI 等构建产物散落在 S3 桶或本地目录中。lib/librdkafka-2.15.0/packaging/nuget/README.md描述的正是这套聚合式打包体系一组 Python 脚本从本地目录或 S3 收集 CI 产物在一个 staging暂存目录中按打包类packaging class定义的包结构重新组装。其中NugetPackage类在 staging 目录之上通过 Docker 内运行的 NuGet 工具生成带完整元数据的 NuGet 包StaticPackage类将各平台的静态库打包成一个自包含的 tarball最终的 NuGet 包可以手工上传到 NuGet.org也可以让脚本自动上传。换句话说这套脚本是多平台 CI 二进制分发的最后一公里把散落在不同构建系统的碎片合并成一个开发者可以dotnet add package librdkafka.redist直接消费的交付物。二、运行环境要求原文档明确给出了三个前置条件位于 packaging/nuget/README.mdPython 3全部打包脚本均为 Python 3 编写DockerNuGet 工具本身在 Docker 容器内运行详见下文nuget.sh上传也依赖 Docker可选私有 S3 访问密钥仅当使用--s3从librdkafka-ci-packages桶收集产物时才需要。依赖清单见 packaging/nuget/requirements.txtboto3~1.38 rpmfile~1.1 filemagic~1.6boto3访问 S3 桶rpmfile解析 RPM 相关文件filemagiclibmagic的 Python 绑定用于校验下载的二进制文件类型与声明的平台/架构是否一致见下文产物真实性校验。三、完整发布流程原文七步走原文档给出了从打标签到上传 NuGet 的完整操作路径逐条继承如下。第 1 步触发 CI 构建在 librdkafka 仓库中创建并推送一个 release或 release candidate标签确保标签打在正确的分支上$ git tag v0.11.0-RC3 $ git push origin v0.11.0-RC3第 2 步等待 CI 构建完成各平台 CI 构建完成后产物会上传到 S3。原文档提供了监控入口SemaphoreCI 的 librdkafka 项目新构建、Travis 与 AppVeyor历史构建。若使用 SemaphoreCI也可以让打包 job 直接依赖同一流水线中的前置构建 job从而免去人工等待。第 3 步运行 release.py 组装 NuGet 包在 Linux 主机上进入packaging/nuget目录执行$ cd packaging/nuget # 指定标签 $ ./release.py v0.11.0-RC3 # 若标签被移动过、需要同时精确匹配某个 git sha # $ ./release.py --sha the-full-git-sha v0.11.0-RC3第 4 步产物齐全后生成 nupkg如果所有产物均已就绪NuGet 包会被构建并输出到当前目录命名为librdkafka.redist.去 v 前缀的标签.nupkg例如librdkafka.redist.0.11.0-RC3.nupkg。第 5 步手动测试包将 nupkg 安装到实际项目中验证链接、运行、依赖如 Windows 下的 VC 运行库均正常。第 6 步上传 NuGet手工上传至 NuGet.org 的包管理页。第 7 步可选自动上传若已信任整个流程可以让release.py构建后自动上传$ ./release.py --retries 100 --upload your-nuget-api.key v0.11.0-RC3四、release.py 命令行参数全解原文档只展示了部分用法结合 packaging/nuget/release.py 的argparse定义完整参数如下参数说明默认值tag位置参数要收集产物的 git 标签必填--s3从 S3 桶收集产物否则只从本地目录收集关闭--dry-run只定位产物不实际下载、不构建任何东西关闭--directory dir下载目录也用于收集本地已有产物dl-tag--no-cleanup构建完成后保留临时目录staging 目录关闭--sha sha1额外按 git sha1 精确匹配产物无--ignore-tag忽略产物中的 tag 属性仅开发用关闭--nuget-version ver指定 NuGet 包版本默认与标签同名标签名--upload key或文件构建后自动上传值为 NuGet API key 或存放 key 的文件路径无--class 类名打包类NugetPackage或StaticPackageNugetPackage--retries n收集产物缺失时的重试次数配合--s3每次间隔 30 秒0几个值得注意的实现细节匹配逻辑release.py先根据--sha/--ignore-tag构造match字典默认{tag: 标签}再叠加所选打包类自带的match属性Artifacts对象用这个字典过滤 S3 中的对象见 packaging.py 的collect_single。重试机制构建过程中若抛出MissingArtifactError且指定了--retries脚本打印错误、清理临时目录、等待 30 秒后重试release.py的 while 循环适合 S3 上传有延迟的场景。key 的两种形式--upload若指向一个已存在的文件则读取文件内容并去除换行作为 API key否则把参数值本身当作 key。上传失败即失败上传通过./push-to-nuget.sh执行退出码非 0 时断言失败并给出错误信息。五、S3 产物命名规范token 编码收集产物时脚本依赖 S3 对象路径中编码的token来完成匹配。规范格式见 packaging.py 的类注释与collect_single的正则token-[value]__ 可重复识别的 token 及含义Token含义示例值p项目librdkafka、confluent-kafka-pythonbld构建系统travis、appveyor、semaphoreplat平台osx、linux、windist发行版/运行时centos8、mingw、msvcr、alpinearch架构x64、x86、arm64、s390xtaggit 标签v0.11.0-RC3shagit sha完整 40 位 shabid构建 ID1562.1bldtype构建类型Release、Debuglnk链接方式std动态、static、all两者都含extra附加选项gssapicyrus-sasl 链接真实路径示例librdkafka/p-librdkafka__bld-travis__plat-linux__arch-x64__tag-v0.0.62__sha-d051b2c19eb0c118991cd8bc5cf86d8e5e446cde__bid-1562.1/librdkafka.tar.gz脚本会做以下归一化与过滤均在packaging.py中实现值重命名rename_vals将windows→win、x86_64/amd64→x64、i386/win32→x86统一 token 取值忽略 Debug 产物bldtypedebug的 AppVeyor 产物被直接丢弃处理未展开的 AppVeyor tokenAppVeyor 在未设置标签时会把$(APPVEYOR_REPO_TAG_NAME)原样留在路径里脚本识别并删除该 token符号包降权文件名含.symbols.的产物 score 减 10在排序中靠后Artifact.__init__common 产物豁免pcommon的通用产物如 VC 运行库 zip不要求 tag 匹配。产物真实性校验filemagic收集到的二进制会按(plat, arch, 扩展名)查表做文件类型校验magic_patterns例如Windows x64 的.dll必须匹配PE32.*DLL.* x86-64, for MS WindowsLinux x64 的.so必须匹配ELF 64.* x86-64macOS x64 的.dylib必须匹配Mach-O 64.* x86_64。校验失败会打印 Warning并且该文件不会被纳入包内apply_mappings中magic_mismatch为真时删除输出文件后继续。这是一道防止架构标错的自动化防线。六、NugetPackage 打包类staging 目录组装原理NugetPackage 类 把所有平台、架构的产物合并进一套 NuGet 输出。其build()流程如下创建临时 staging 目录out-*前缀渲染templates/librdkafka.redist.nuspec模板版本号代入${version}复制librdkafka.redist.targets到build/native/、librdkafka.redist.props到build/为每个产物补充variant形如linux-x64-release与toolset默认v142字段调用apply_mappings()按映射表抽取归档内文件到目标路径调用./nuget.sh pack nuspec路径 -BasePath staging -NonInteractive生成 nupkg版本号自动去掉前缀v。6.1 映射表产物文件 → 包内路径mappings是一个Mapping对象列表每个映射声明匹配哪些产物属性attributes、匹配哪种文件名artifact_fname_glob、从归档中抽取哪个文件path_in_artifact、放到包内哪个路径output_pkg_path缺省与源路径相同。属性键以!开头表示必须不匹配。关键映射示例nugetpackage.py头文件Linux x64std链接的librdkafka.tgz中的rdkafka.h、rdkafkacpp.h、rdkafka_mock.h→build/native/include/librdkafka/文档README.md、CONFIGURATION.md、LICENSES.txt→ 包根目录运行时动态库runtimes/rid/native/对应 .NET 的 Runtime IdentifiermacOS x64librdkafka.dylib→runtimes/osx-x64/native/macOS arm64librdkafka.1.dylib→runtimes/osx-arm64/native/Linux glibccentos8x64librdkafka.so.1→runtimes/linux-x64/native/librdkafka.so另有无 GSSAPI 依赖的centos8-librdkafka.so变体Linux glibc arm64/s390x、Linux muslalpinex64/arm64各自的librdkafka.so变体Windows x64/x86librdkafka.dll、librdkafkacpp.dll、OpenSSLlibcrypto-3-*.dll、libssl-3-*.dll、z.dll、zstd.dll、libcurl.dll以及从common目录抽取的vcruntime140.dll、msvcp140.dllVC 运行库Windows 链接库.liblibrdkafka.lib、librdkafkacpp.lib→build/native/lib/win/x64|/x86/win-x64|win-x86-Release/v142/。6.2 nuspec 模板与 MSBuild 集成templates/librdkafka.redist.nuspec定义了包元数据ID 为librdkafka.redist、标题 librdkafka - redistributable、filesfile src** //files打包整个 staging 目录。注意 nuspec 中的${version}是由Package.render()用string.Template替换的见 packaging.py 的render方法。templates/librdkafka.redist.targets则负责消费侧自动集成当 .NET 项目引用该包时MSBuild 会自动按$(Platform)是否为x64附加对应的librdkafka.lib到AdditionalDependencies并设置AdditionalLibraryDirectories把头文件目录加入AdditionalIncludeDirectories通过ReferenceCopyLocalPaths把runtimes/win-x64/native/*.dll或 x86拷贝到输出目录。也就是说NuGet 消费者拿到的不只是二进制还有一整套即装即用的构建集成。6.3 nuget.shDocker 内的 NuGet 工具nuget.sh 是 NuGet 工具的前端封装若已在 Docker 容器内存在/.dockerenv则直接调用宿主nuget否则用mono:latest镜像挂载当前目录运行docker run -v $(pwd):/io mono:latest /io/$0 $*这解释了 README 中NuGet tool is then run (from within docker)的含义——打包主机不需要安装 .NET/mono只需有 Docker。七、StaticPackage自包含静态库 bundle除了 NuGet--class StaticPackage可生成一个 librdkafka 自包含静态库的 tarball$ ./release.py --class StaticPackage v1.1.0输出文件名为librdkafka-static-bundle-版本.tgz。根据 staticpackage.py 的注释这些静态库后续会被导入 confluent-kafka-go 使用。其映射表有两个显著特征排除 GSSAPI绝大多数映射带!extra: gssapi负向匹配因为 cyrus-sasl 是动态链接会破坏自包含例外是 macOScyrus-sasl 始终可用与 Windows从不链接。重命名产物静态库按运行时 平台重命名例如librdkafka_glibc_linux_amd64.a/librdkafka_glibc_linux_arm64.a/librdkafka_glibc_linux_s390x.acentos8librdkafka_musl_linux_amd64.a/librdkafka_musl_linux_arm64.aalpinelibrdkafka_darwin_amd64.a/librdkafka_darwin_arm64.alibrdkafka_windows.amingw每个.a还配套对应的rdkafka-static.pcpkg-config 文件重命名为librdkafka_*.pc。构建流程与 NuGet 类似创建 staging 目录 →apply_mappings()抽取文件 →tar cvzf打包build()中的subprocess.check_call。八、S3 桶清理cleanup-s3.py长期运行 CI 会在 S3 桶里积累大量非发布产物cleanup-s3.py 负责清理# 先检查只列出不删除 $ AWS_PROFILE.. ./cleanup-s3.py --age 360 # 确认无误后真正删除 $ AWS_PROFILE.. ./cleanup-s3.py --age 360 --delete--age 天只处理最后修改时间早于 N 天的对象默认 360 天判定可删除的标准may_delete路径中没有 tag或 tag 不匹配^v?\d\.\d\.\d(-?RC\d)?$即非正式 release / 非 RC 标签同时沿用与packaging.py相同的 token 解析逻辑包括处理 AppVeyor 未展开的$(token删除按每次最多 1000 个对象分块调用 S3 的delete_objectsS3 API 上限任一错误即抛异常中止未加--delete时默认是 dry-run只打印Eligible for deletion清单避免误删。九、发布后的验证与上传实现verify() 校验无论是 NugetPackage 还是 StaticPackage构建完成后release.py都会调用所选打包类的verify()继承自 packaging.py 的Package.verify以只读方式打开输出包nupkg 本质是 zip把 zip 内的文件名做 URL 解码后与所有 mapping 的output_path逐一比对缺失任何一个即校验失败并以退出码 1 终止。校验通过会打印OK - N expected files found。push-to-nuget.sh 上传push-to-nuget.sh 通过 Docker 运行 .NET SDK 完成上传docker run -t -v $PWD/$pkg:/$pkg mcr.microsoft.com/dotnet/sdk:3.1 \ dotnet nuget push /$pkg -n -s https://api.nuget.org/v3/index.json \ -k $key --source https://api.nuget.org/v3/index.json-n表示非交互-k传入 API key。手工上传则走 NuGet.org 的网页管理入口。注意本文不展开外部站点细节按原文档步骤执行即可。十、在 fluent-bit 仓库中的定位与扩展阅读在当前的 fluent-bit 仓库中librdkafka 以整棵源码树内嵌于 lib/librdkafka-2.15.0供out_kafka输出插件使用参见 plugins/out_kafka而本文介绍的打包脚本位于 lib/librdkafka-2.15.0/packaging/nuget属于 librdkafka 自身的发布工程链与 fluent-bit 的构建见 CMakeLists.txt相互独立——fluent-bit 直接以源码/子模块方式编译链接 librdkafka而非消费 NuGet 包。若希望进一步研究建议按以下顺序阅读packaging/nuget/README.md流程总览本文主体packaging/nuget/release.pyCLI 入口与重试/上传编排packaging/nuget/packaging.pyArtifact/Artifacts/Mapping/Package 四大核心类packaging/nuget/nugetpackage.py 与 packaging/nuget/staticpackage.py两种打包类的完整映射表packaging/nuget/templatesnuspec、props、targets 三个集成模板。小结这套packaging/nuget脚本把 librdkafka 的多平台 CI 产物收敛为两种可分发交付物面向 .NET 生态的librdkafka.redist.版本.nupkg含头文件、各 RID 的运行时库、MSBuild 自动集成以及面向 confluent-kafka-go 等项目的自包含静态库 tarball。其核心设计——token 化命名约定、映射表驱动的 staging 组装、filemagic 类型校验、构建后 verify 自检——对于任何需要多平台二进制聚合分发的 C/C 项目都具有直接的可借鉴价值。【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考