DataHub Airflow 插件发布指南深入解析 release.sh 自动化发布脚本【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读metadata-ingestion-modules/airflow-plugin/scripts/目录是 DataHub Airflow 插件acryl-datahub-airflow-plugin发布流程的存放位置其中核心脚本release.sh负责完成从构建、测试、版本号改写到打包上传 PyPI 的完整发布链路。本文以该目录的 README.md 为线索逐行剖析release.sh的执行逻辑、环境变量控制点与版本号写入机制并对照脚本生成器与setup.py配置帮助读者理解 DataHub 各 Python 插件统一的发布管线掌握可复制到自身项目中的发布脚本设计范式。一、scripts 目录的定位scripts/README.md 对目录的定位说明非常简洁该目录存放 DataHub Airflow 插件的实用脚本utility scripts。当前目录下只有两个文件README.md目录说明文档release.sh发布脚本README 中标注其用途为用于发布插件预先存在的pre-existing。release.sh本身并非手工维护的独有脚本而是由仓库根目录下的 generate_release_scripts.py 自动生成——脚本首行注释明确写着# Auto-generated by python-build/generate_release_scripts.py. Do not edit manually.。这意味着理解release.sh的完整语义需要同时阅读生成器模板与插件的打包配置。二、release.sh 全脚本解析以下是仓库中 release.sh 的完整内容#!/bin/bash # Auto-generated by python-build/generate_release_scripts.py. Do not edit manually. set -euxo pipefail ROOT../.. MODULEdatahub_airflow_plugin if [[ ! ${RELEASE_SKIP_TEST:-} ]] [[ ! ${RELEASE_SKIP_INSTALL:-} ]]; then ${ROOT}/gradlew build # also runs tests elif [[ ! ${RELEASE_SKIP_INSTALL:-} ]]; then ${ROOT}/gradlew install fi # Check packaging constraint. python -c import setuptools; where./src; assert setuptools.find_packages(where) setuptools.find_namespace_packages(where), you seem to be missing or have extra __init__.py files # Update the release version. if [[ ! ${RELEASE_VERSION:-} ]]; then echo RELEASE_VERSION is not set exit 1 fi sed -i.bak s/__version__ .*$/__version__ \$(echo $RELEASE_VERSION|sed s/-//)\/ src/${MODULE}/_version.py # Build and upload the release. rm -rf build dist || true python -m build if [[ ! ${RELEASE_SKIP_UPLOAD:-} ]]; then python -m twine upload dist/* fi mv src/${MODULE}/_version.py.bak src/${MODULE}/_version.py2.1 脚本头部安全模式与关键变量set -euxo pipefail ROOT../.. MODULEdatahub_airflow_pluginset -euxo pipefail一次性启用了四类严格行为-e任一命令失败即退出、-u使用未定义变量即报错、-x打印每条即将执行的命令便于 CI 日志排查、-o pipefail管道中任一环节失败即视为整体失败。这是发布脚本的标配确保任何一步出错都会立即中断避免带着半成品继续上传。ROOT../..指向仓库根目录。从 generate_release_scripts.py 的root_from_directory()方法可以看出该路径由包目录层级数自动推导metadata-ingestion-modules/airflow-plugin含两级子目录因此向上回退两层。MODULEdatahub_airflow_plugin对应插件的 Python 主模块名与 setup.py 中package_dir{: src}及src/下的实际包目录 datahub_airflow_plugin 一一对应。2.2 构建阶段gradlew build 与 install 的选择if [[ ! ${RELEASE_SKIP_TEST:-} ]] [[ ! ${RELEASE_SKIP_INSTALL:-} ]]; then ${ROOT}/gradlew build # also runs tests elif [[ ! ${RELEASE_SKIP_INSTALL:-} ]]; then ${ROOT}/gradlew install fi这是脚本的第一个分支控制点逻辑如下默认两个环境变量均未设置执行${ROOT}/gradlew build该任务会同时运行测试若设置了RELEASE_SKIP_TEST跳过测试则退化为仅执行gradlew install若设置了RELEASE_SKIP_INSTALL跳过安装/构建阶段则整个构建块被跳过。这里借助了${VAR:-}的 Shell 默认值语法变量未设置时展开为空字符串[[ ! ]]为真因此默认行为是完整构建。gradlew是仓库根目录下的 Gradle Wrapper 启动器DataHub 使用 Gradle 统一驱动整个仓库的多模块构建与代码生成包括 Python 包的 PDL 模型代码生成发布前先跑 Gradle 构建可确保src/下的生成代码是最新的。2.3 打包约束检查python -c import setuptools; where./src; assert setuptools.find_packages(where) setuptools.find_namespace_packages(where), you seem to be missing or have extra __init__.py files这一行验证包发现的一致性find_packages要求每个目录都含__init__.py而find_namespace_packages允许隐式命名空间包。若两者结果不一致说明src/下存在多余或缺失的__init__.py断言失败会直接终止脚本配合set -e。这是 DataHub 对 Python 包结构强约束的体现——所有模块必须是显式常规包避免因隐式命名空间包导致的打包遗漏。2.4 版本号写入RELEASE_VERSION 的强制与改写if [[ ! ${RELEASE_VERSION:-} ]]; then echo RELEASE_VERSION is not set exit 1 fi sed -i.bak s/__version__ .*$/__version__ \$(echo $RELEASE_VERSION|sed s/-//)\/ src/${MODULE}/_version.py发布版本号必须通过环境变量RELEASE_VERSION显式传入未设置时打印提示并退出exit 1。随后用sed -i.bak原地改写 src/datahub_airflow_plugin/_version.py 中的__version__赋值行匹配模式__version__ .*$命中文件中形如__version__ ...的行值来自$(echo $RELEASE_VERSION | sed s/-//)即将版本号中的-全部替换为。这是 PEP 440 本地版本标识的规范化处理——例如传入1.7.0-rc1会被改写为1.7.0rc1保证生成的版本号符合 Python 打包规范-i.bak在改写前生成_version.py.bak备份为脚本末尾的恢复操作做准备。版本号最终会被 setup.py 读取setup.py通过exec加载_version.py拿到__version__并据此构造对acryl-datahub主包的{_version}自固定依赖除非版本是dev0/dev1或以docker结尾确保插件与主库版本严格对齐发布。2.5 构建 wheel 与上传 PyPIrm -rf build dist || true python -m build if [[ ! ${RELEASE_SKIP_UPLOAD:-} ]]; then python -m twine upload dist/* fi mv src/${MODULE}/_version.py.bak src/${MODULE}/_version.pyrm -rf build dist || true清理上次构建产物|| true保证目录不存在时rm报错不触发set -e中断python -m build基于 pyproject.toml 声明的构建后端setuptools.build_meta生成 sdist 与 wheel默认调用python -m twine upload dist/*上传所有构建产物到 PyPI凭据来自~/.pypirc或 CI 环境可通过RELEASE_SKIP_UPLOAD跳过——这是本地试打包的常用手段最后mv将备份的_version.py.bak还原使工作区源码保持发布前的版本号状态避免污染后续开发。三、四个环境变量的控制矩阵综合上述流程release.sh暴露了 4 个环境变量构成完整的发布控制矩阵环境变量默认行为设置后效果典型用途RELEASE_VERSION无未设置直接报错退出指定发布版本号-会被改写为每次发布必填如1.7.0、1.7.0-rc1RELEASE_SKIP_TEST构建阶段运行gradlew build含测试构建退化为gradlew install快速验证打包、跳过耗时测试RELEASE_SKIP_INSTALL执行 Gradle 构建/安装跳过整个构建阶段仅重新打包已就绪的源码RELEASE_SKIP_UPLOAD执行twine upload只构建不上传本地试打包、CI 产物校验一个典型的完整发布命令形如RELEASE_VERSION1.7.0 ./scripts/release.sh而只验证打包、不上传的命令为RELEASE_VERSION1.7.0-rc1 RELEASE_SKIP_UPLOAD1 ./scripts/release.sh四、脚本的生成机制一处模板、七处发布generate_release_scripts.py 将同一发布模板批量渲染到仓库中所有 Python 发行包其packages列表覆盖metadata-ingestion模块datahubdatahub-actions模块datahub_actionsdatahub-agent-context模块datahub_agent_contextmetadata-ingestion-modules/airflow-plugin模块datahub_airflow_pluginmetadata-ingestion-modules/dagster-plugin模块datahub_dagster_pluginmetadata-ingestion-modules/gx-plugin模块datahub_gx_pluginmetadata-ingestion-modules/prefect-plugin模块prefect_datahub生成器核心逻辑generate_release_scripts.py#L43-L77root_from_directory()按目录层级数计算ROOT回退深度保证gradlew调用路径正确模板内使用%s占位符依次注入生成头注释、ROOT、MODULE对每个包执行script_path.write_text(...)生成scripts/release.sh。因此读者在 Airflow 插件、Dagster 插件、GX 插件乃至datahub-actions等目录下看到的scripts/release.sh结构完全一致仅ROOT与MODULE不同。脚本首行的Do not edit manually不是装饰——任何针对发布流程的修改都应落到python-build/generate_release_scripts.py的模板中再重新生成避免各包脚本漂移。五、与打包配置的联动setup.py 与 pyproject.tomlrelease.sh的每一步背后都有 setup.py 与 pyproject.toml 的支撑理解这些配置才能完整把握发布产物内容入口点声明setup.py#L103-L106entry_points { airflow.plugins: acryl-datahub-airflow-plugin datahub_airflow_plugin.datahub_plugin:DatahubPlugin, apache_airflow_provider: [provider_infodatahub_provider:get_provider_info], }发布后的 wheel 正是通过这两个入口点被 Airflow 识别为插件与 Provider。依赖与 extrassetup.py#L25-L48基础依赖固定apache-airflow3.0.0,4.0.0与apache-airflow-providers-openlineage2.1.0并按 emit 方式提供datahub-rest、datahub-kafka、datahub-file三个 extras其中datahub-rest被默认并入基础依赖。这意味着twine upload上传的包其功能完备性在发布前已由setup.py的依赖解析保证。构建后端pyproject.toml#L1-L3[build-system] build-backend setuptools.build_meta requires [setuptools78.1.1, wheel, pip21.0.0]python -m build即按此声明拉取构建依赖并调用setuptools.build_meta完成打包。此外python_requires3.10setup.py#L142界定了发布产物的运行环境下限。六、实践建议与注意事项版本号格式RELEASE_VERSION最终进入 src/datahub_airflow_plugin/_version.py并被setup.py用作对acryl-datahub的自固定依赖发布非最终版本如 rc、snapshot时-自动转为以满足 PEP 440无需手工换算。先本地试跑发布前务必用RELEASE_SKIP_UPLOAD1组合执行一次检查dist/下生成的 sdist 与 wheel 是否符合预期可进一步用twine check dist/*校验元数据。不要手工编辑脚本所有 DataHub Python 包的scripts/release.sh均由 generate_release_scripts.py 统一生成需要改动发布流程时应修改生成器模板后重新生成。CI 场景脚本基于set -euxo pipefail配合-x的输出便于在 CI 日志中追踪每一步命令RELEASE_SKIP_TEST与RELEASE_SKIP_INSTALL可用于分层流水线如测试与打包分离的 Job。插件运行前置条件发布并安装插件后还需在airflow.cfg中启用[datahub] enabled True并配置指向 DataHub GMS 的 Airflow Connection详见插件的 README.md发布脚本本身只负责产物的构建与上传不涉及运行时配置。总而言之scripts/release.sh虽在 README 中仅以一行说明但其背后是一套贯穿 Gradle 构建、打包约束校验、版本规范化、PyPI 上传的完整发布管线并且与仓库中其余 6 个 Python 发行包共享同一生成模板。掌握它的执行分支与环境变量语义即可对 DataHub 生态中任何 Python 插件的发布流程做到心中有数。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考