Apache Airflow Breeze 发布管理命令实战指南从发行包构建、RC 验证到约束与文档发布【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflowApache Airflow 的开发环境工具 BreezeBreeze 是 Airflow 维护者日常使用的命令行工具源码位于 dev/breeze除了支撑日常开发与 CI 任务外还内置了一整套发布管理release management命令。本文以 dev/breeze/doc/09_release_management_tasks.rst 为骨架结合 release_management_commands.py 与 release_management_validation.py 的源码实现系统讲解 Airflow 核心、Helm Chart、Provider、Task SDK、airflowctl、Python Client、Mypy 发行包以及约束文件、SBOM、文档发布的完整命令族。读完本文你将掌握如何构建并验证各类发行包、如何自动化创建 minor 分支与 RC、PMC 成员如何交叉验证发布候选、如何管理约束文件与发布生产镜像以及如何把文档发布到 airflow-site 与 S3。说明这些命令大多需要发布管理员Release ManagerRM或 PMC 成员的权限与凭证普通贡献者通常无需也无法运行。Airflow 核心与 Provider 的完整发布流程分别记录在 dev/README_RELEASE_AIRFLOW.md 与 dev/README_RELEASE_PROVIDERS.md 中本文聚焦 Breeze 命令行本身。所有发布管理命令统一挂在breeze release-management subcommand之下命令组定义于 release_management_group.py其下按“Airflow 发行 / Helm Chart 发行 / Provider 发行 / 约束管理 / 其他 / SBOM”几大类划分本文将依次展开。一、Airflow 核心发行命令1. 准备 Airflow 发行包prepare-airflow-distributions构建 Airflow 的.whl与.tar.gzsdist发行包是最基础的一步breeze release-management prepare-airflow-distributions默认同时构建sdist与wheel两种格式可用--distribution-format指定单一格式breeze release-management prepare-airflow-distributions --distribution-formatwheel从源码看release_management_commands.py该命令的执行链路是perform_environment_checks()检查环境、fix_ownership_using_docker()修正容器文件属主、cleanup_python_generated_files()清理生成的 Python 文件通过get_source_date_epoch(AIRFLOW_ROOT_PATH)取得可复现构建所需的SOURCE_DATE_EPOCH时间戳支持两条构建路径本地hatch build--use-local-hatch或在 Docker 构建镜像内执行hatch build -c -t sdist/-t wheel构建完成后还会对sdist做“能否重新构建为 wheel”的自检_check_sdist_to_wheel_dists确保 sdist 内容完整。产物统一输出到仓库根目录的dist文件夹。若传入--tag参数对应 git 中的实际 tag会在 sdist 之外额外生成 source tarball 发布包。2. 准备源码 tarballprepare-tarball按 ASFApache Software Foundation发布政策官方发布必须以源码 tarball 为准。Breeze 提供breeze release-management prepare-tarball该命令在dist目录生成airflow-*-source.tar.gz。可通过--tarball-type指定为哪个发行物准备 tarball默认是apache_airflow版本号自动取自--tagbreeze release-management prepare-tarball --tarball-type apache_airflow_ctl其底层实现在 release_candidate_command.py 的tarball_release/create_tarball_release中支持从分支 HEAD未打 tag或指定 tag 构建并配合--source-date-epoch保证可复现。3. PMC 验证发布候选verify-rc-by-pmcPMC 成员可以用 Breeze 对发布候选RC做自动化交叉验证作为手工验证的补充。完整的手工流程见 dev/README_RELEASE_AIRFLOW.md 中 “Verify the release candidate by PMC members” 一节。需要强调当自动化输出与手工验证不一致时以手工验证为准并上报差异。该命令校验以下内容源码见 release_management_validation.pySVN 发布目录中的文件GPG 签名.ascSHA512 校验和.sha512Apache RAT 许可证检查可复现构建reproducible build。典型用法同时验证 Airflow 与 Task SDK 两个 RCbreeze release-management verify-rc-by-pmc \ --distribution airflow \ --version 3.1.3rc1 \ --task-sdk-version 1.1.3rc1 \ --path-to-airflow-svn ~/asf-dist/dev/airflow也可以只运行部分检查通过--checks指定可用值为reproducible-build, svn, licenses, signatures, checksums默认全部breeze release-management verify-rc-by-pmc \ --distribution airflow \ --version 3.1.3rc1 \ --task-sdk-version 1.1.3rc1 \ --path-to-airflow-svn ~/asf-dist/dev/airflow \ --checks reproducible-build,svn,licenses,signatures,checksums实现要点Implementation notes可复现构建校验会 checkout 发布 tag用与 dev/README_RELEASE_AIRFLOW.md 中相同的 Breeze 命令构建包再与 SVN 上的工件对比校验器会对SVN working copy 锁做快速检查提前失败而不是卡死在svn命令上防止挂起。支持的发行物Supported distributions目前仅支持--distribution airflowproviders、airflowctl、python-client等取值是为未来扩展预留的尚未实现。弃用说明重要除reproducible-build之外的所有检查将在完全迁移到 Apache Trusted ReleasesATR后被弃用迁移完成后可复现构建检查将是唯一保留的自动化验证手段。该命令还覆盖了针对历史 SVN 快照固定 revision的 Breeze 集成测试以保证行为长期稳定。4. 创建 Airflow minor 分支create-minor-branch新建 Airflow 的 minor 分支如2-10-test、2-10-stable需要执行若干维护任务该命令将其自动化breeze release-management create-minor-branch底层逻辑见 minor_release_command.py包括创建 version branch、更新默认分支、提交变更、创建 stable 分支、推送 test/stable 分支、回切 main、为分支生成约束文件等步骤。5. 启动 RC 流程与最终发布流程准备发布候选时Breeze 可以自动化部分步骤breeze release-management start-rc-process准备最终发布时同样可以自动化部分步骤breeze release-management start-release两者背后对应 release_candidate_command.py 与 release_command.py 中从打 tag、生成 tarball、签名、生成约束、上传 SVN 到推 PyPI 的一整套流程函数。6. 生成 Airflow 核心发布 Issuegenerate-issue-content-core发布新版 Airflow 时可以用 Breeze 生成 core 发布跟踪 Issue 的模板内容PR 列表、关联 Issue、贡献者统计等实现位于generate_issue_content_corerelease_management_commands.pybreeze release-management generate-issue-content-core7. 准备 Python Clientprepare-python-clientPython 客户端源码可以通过代码生成得到并构建其发行包。前提是本地已 checkout python client 仓库breeze release-management prepare-python-client --python-client-repo ~/code/airflow-client-python该命令支持以自定义 security schemes 重新生成客户端源码见prepare_python_clientrelease_management_commands.py它先由 OpenAPI 规范生成 Python 客户端源码到临时目录再做fix_anyof_null_and_required等补丁处理最后复制到clients/python并以 hatch 构建。Python 客户端的完整发布说明见 dev/README_RELEASE_PYTHON_CLIENT.md。8. 发布生产镜像release-prod-images生产镜像Production image由具备 DockerHub 推送权限的发布管理员发布通常只在 RC 或最终版本发布时进行。正常情况下由 CI 的 “Release PROD images” workflow 完成内部即调用本命令本地手动执行需满足“发布管理员 具备 DockerHub registry 写权限”。普通regular与精简slim镜像是分两步分别发布的。发布普通镜像breeze release-management release-prod-images --airflow-version 3.0.0发布 slim 镜像breeze release-management release-prod-images --airflow-version 3.0.0 --slim-imageslatest 标签策略默认发布“最终版”镜像时会额外打上latest系列标签可通过--skip-latest跳过。规则是最后最新的 Python 版本会被打成不带 Python 后缀的镜像例如airflow-3.0.0-python3.12同时被打为airflow-3.0.0如果airflow-3.0.0是最新版本则airflow-3.0.0-python3.12→airflow-latestairflow-3.0.0-python3.12→airflow-latest-python3.12airflow-3.0.0-python3.11→airflow-latest-python3.11以此类推。多平台构建默认命令使用模拟emulation构建多平台镜像或者要求本机 buildx driver 已配置多硬件支持——模拟构建很慢多硬件配置较复杂具体步骤见 dev/MANUALLY_BUILDING_IMAGES.md。跨硬件构建metadata-folder 模式另一种方式是传入--metadata-folder指定元数据目录在每种硬件上分别构建。此时镜像以digest-only只推 digest、不打 tag方式推送到 registrydigest 信息写入本地生成的 metadata 文件随后把这些不同硬件生成的 metadata 文件汇集到一台机器上用下一节的merge-prod-images合并发布为多平台镜像。该模式下跳过打 tag 步骤tag 只在合并时执行。breeze release-management release-prod-images --airflow-version 3.0.0 --metadata-folder dist breeze release-management release-prod-images --airflow-version 3.0.0 --slim-images --metadata-folder dist从源码release_management_commands.py可以看到构建参数细节基础镜像为debian:bookworm-slim约束模式为constraints-no-providers支持COMMIT_SHA注入slim 镜像会置空AIRFLOW_EXTRAS--metadata-folder模式下用--metadata-file输出并push-by-digesttrue非 metadata 模式则直接打{dockerhub_repo}:{airflow_version}-python{python}标签并在默认 Python 版本上额外执行alias_image。9. 合并生产镜像merge-prod-images承接上一节当你在不同硬件ARM、AMD 分开构建镜像并以 digest-only 推送后把 metadata 文件汇集到一台机器运行breeze release-management merge-prod-images --airflow-version 3.0.0 --metadata-folder distslim 镜像同样单独合并breeze release-management merge-prod-images --airflow-version 3.0.0 --slim-images --metadata-folder dist默认在合并“最终版”时打latest标签可用--skip-latest跳过合并后的镜像会在 DockerHub 上以合适的别名alias呈现。10. 为 Provider 添加 git tagstag-providers在 Provider 发布期间需要向 apache/airflow 远端仓库推送 Provider 的 git tags。由于有时与 GitHub 的连接问题本地可能残留已创建的 tag 并导致恼人的错误——默认行为是清理这类本地 tag若想保留可将环境变量CLEAN_LOCAL_TAGS设为 false或显式传--no-clean-tags用--clean-tags则强制删除本地 tagbreeze release-management tag-providers从源码release_management_commands.py看该命令按upstream→origin→apache的顺序探测指向apache/airflow.git的远端然后扫描dist目录中的 provider wheel 文件按providers-name/version的命名规则如providers-amazon/8.0.0创建带“Release release_date of providers”消息的 tag并推送。二、Helm Chart 发行命令1. 准备 Helm Chart 源码 tarballprepare-helm-chart-tarballbreeze release-management prepare-helm-chart-tarball该命令在dist目录生成 helm chart 的-source.tar.gz包。必须通过--version与--version-suffix指定要发布的 Helm Chart 版本breeze release-management prepare-helm-chart-tarball --version 1.12.0 --version-suffix rc12. 准备 Helm Chart 包prepare-helm-chart-packagebreeze release-management prepare-helm-chart-package在dist目录生成 helm chart 的.tar.gz安装包。可选地使用--sign传入你的 Apache 邮箱进行 GPG 签名breeze release-management prepare-helm-chart-package --sign myemailapache.org3. 生成 Helm Chart 发布 Issuegenerate-issue-content-helm-chartbreeze release-management generate-issue-content-helm-chart发布新版 helm chart 时用该命令生成发布跟踪 Issue 内容实现见generate_issue_content_helm_chartrelease_management_commands.py。Helm Chart 完整发布流程见 dev/README_RELEASE_HELM_CHART.md。三、Provider 发行命令Provider 发布是发布管理员职责的一部分完整流程见 dev/README_RELEASE_PROVIDERS.md。1. 准备 Provider 文档prepare-provider-documentationbreeze release-management prepare-provider-documentation为 Provider 准备生成文档。可加--answer yes进行非交互式构建。2. 分类 Provider 变更classify-provider-changes该命令使用硬编码的高置信度规则对每个 Provider 未发布的变更进行分类将歧义 commit 标记为needs_llm交给 Agent 或 skill 评估。结果以JSON输出为纯变更发现提供了一种确定性的替代方案区别于仅用于变更发现的--non-interactive文档运行breeze release-management classify-provider-changes3. 更新 Provider 下一个版本引用update-providers-next-version自动把对依赖 Provider 的引用更新到其“下一版本”前提是这些引用处带有# use next version或#use next version#后无空格注释breeze release-management update-providers-next-version4. 构建 Provider 发行包prepare-provider-distributions所有发行包构建到dist目录。注意该命令运行前会清空dist目录所以应在生成 Airflow 包之前运行否则会被清掉。默认构建wheel与sdist两种格式用--distribution-format可指定# 仅 wheel breeze release-management prepare-provider-distributions --distribution-format wheel # wheel sdist breeze release-management prepare-provider-distributions不指定 provider 时构建全部也可以指定部分breeze release-management prepare-provider-distributions google amazon查看所有可选 providerbreeze release-management prepare-provider-distributions --help若传--tag对应 git 实际 tag会在 sdist 之外额外生成 source tarball。重要构建前的 git clean 行为。每个 provider 构建前Breeze 会在其源码目录内执行git clean -fdx -e .venv -e .idea -e .vscode这会删除该路径下所有未跟踪与 .gitignore 的文件——本地生成的文档docs/_api、sphinx 缓存、__pycache__、*.egg-info以及 RM 迭代时产生的临时文件都在其列。之所以必须清理是因为基于 flit 的 provider 使用显式的[tool.flit.sdist]include 列表扫描docs/、tests/、src/目录而非询问 git任何树内残留都会泄漏进 sdist/wheel破坏与 dist.apache.org 上已发布工件的可复现性。仓库根目录的.venv、.idea、.vscode不受影响——它们位于任何 provider 目录之外也不在任何 flit include 路径中。-e .venv等排除项只是为“有人在 provider 目录内放了 per-provider venv 或 IDE 配置”的罕见情况兜底此时清理仍会保留它们。在破坏性清理之前会先打印一次git clean -ndx ...的 dry-run 清单让你预览将要删除的文件。5. 安装 Provider 发行包install-provider-distributions某些场景只想确认生成的 provider 能否与 Airflow 一起安装而不做完整验证。CI 中sdist包会自动执行此操作你也可以在刚构建完 providerdist目录中有产物后手动运行breeze release-management install-provider-distributions也可指定更早的 Airflow 版本做兼容性验证breeze release-management install-provider-distributions --use-airflow-version 2.4.06. 验证 Provider 发行包verify-provider-distributions验证 provider 类是否可导入、命名是否符合约定。CI 会自动执行也可手动运行需要dist目录中有刚构建的产物breeze release-management verify-provider-distributions breeze release-management verify-provider-distributions --use-airflow-version 2.4.07. 生成 Provider 元数据generate-providers-metadata发布管理员可生成每个 provider 版本的元数据——包括与该 provider 版本关联的 Airflow 版本即 provider 发布后第一个发布的 Airflow 版本以及该 provider 版本的发布日期breeze release-management generate-providers-metadata8. 生成 Provider 发布 Issuegenerate-issue-content-providersbreeze release-management generate-issue-content-providers发布新 provider 时生成发布跟踪 Issue 内容实现见 release_management_commands.py。9. 清理旧 Provider 工件clean-old-provider-artifactsProvider 发布期间需要清理 SVN 发布目录中的旧 provider 版本此前靠脚本完成现已迁移为 Breeze 命令以减轻发布管理员负担breeze release-management clean-old-provider-artifacts四、约束Constraints管理1. 生成约束generate-constraints每当pyproject.toml被修改CI main job 都会重新生成约束文件这些文件存储在独立的孤儿分支中constraints-main、constraints-2-0等。约束文件的详细说明见 contributing-docs/13_airflow_dependencies_and_extras.rst 中 “Pinned constraint files” 一节。也可手动为全部或指定 Python 版本、指定约束模式生成约束breeze release-management generate-constraints --airflow-constraints-mode constraints警告要生成约束必须先为所有 Python 版本用--upgrade-to-newer-dependencies标志构建全部镜像。源码release_management_commands.py中会在运行时交互确认这一点若未构建会提示breeze ci-image build --python 3.12 --upgrade-to-newer-dependencies # 并行模式 breeze ci-image build --run-in-parallel --python-versions 3.9 3.10 3.11 3.12 --upgrade-to-newer-dependencies约束按 Python 版本分别生成共有三种约束模式模式说明用途constraints由源码中的当前 Airflow 版本 从 PyPI 安装的 providers 匹配生成用户pip install airflow时使用的约束constraints-source-providers使用当前源码中的 providers 生成providers 依赖可能随新增而变化CI 用它维持“稳定”约束集constraints-no-providers仅由 Apache Airflow 本身生成不含任何 provider想单独管理 Airflow、再逐个添加 provider 时使用若有人修改了pyproject.toml定时 CI Tests 会自动升级并推送约束文件变更也可本地跑一遍验证流程见 dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md可利用本机多处理器加速。生成过程会把约束文件升级到最新版本、记录pyproject.toml的哈希生成的约束与pyproject.toml哈希文件存放在files文件夹并打印相对上一版的差异 diff。2. 更新约束update-constraints极少数情况下需要更新过去已生成并打 tag 的约束中的个别发行包breeze release-management update-constraints更新约束时会发生什么详见 dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md。五、文档发布与其他发布命令1. 发布文档到 airflow-sitepublish-docs将build-docs生成的文档发布到airflow-site仓库breeze release-management publish-docs发布过程包含三步checkout 已克隆airflow-site的最新main→ 将文档复制到airflow-site→ 运行 post-docs 脚本为文档新版本生成反向引用 HTML。可指定 provider idprovider 名的短形式只发布特定 providerbreeze release-management publish-docs amazon--package-filter用 glob 匹配完整包名一个过滤器可选中多个包适合发布期选择性发布breeze release-management publish-docs apache-airflow-providers-microsoft*--override-versioned为布尔标志发布文档时覆盖 versioned 目录breeze release-management publish-docs --override-versioned--airflow-site-directory接收已克隆airflow-site的路径路径非法时命令不会继续breeze release-management publish-docs --airflow-site-directory path-to-airflow-siteprovider 可使用短名称代替全名短名称的生成方法见源码文档中的generating_short_form_names说明。多处理器机器上为多个 provider 发布文档时用--run-in-parallel可大幅提速。2. 添加反向引用 HTMLadd-back-references为build-docs生成的文档在airflow-site中添加反向引用用于支持 Airflow 文档的向后兼容。必须指定要处理的发行物例如所有 providersbreeze release-management add-back-references --airflow-site-directory DIRECTORY all-providers也可以针对 apache-airflow 核心文档、helm-chart 包或任意混搭列表可自动补全breeze release-management publish-docs --airflow-site-directory DIRECTORY apache-airflow breeze release-management publish-docs --airflow-site-directory DIRECTORY helm-chart breeze release-management publish-docs --airflow-site-directory DIRECTORY apache.airflow apache.beam google3. 发布文档到 S3publish-docs-to-s3将build-docs生成的文档发布到 S3。应在breeze release-management publish-docs之后执行因为需要 airflow-site 的docs-archive目录内容breeze release-management publish-docs-to-s3核心参数为--source-dir-pathdocs-archive 路径与--destination-locationS3 bucket 路径breeze release-management publish-docs-to-s3 --source-dir-path /User/pavan/airflow-site/docs-archive \ --destination-location s3://airflow-docs/docs常用标志# 排除某些文档 breeze release-management publish-docs-to-s3 --source-dir-path /User/pavan/airflow-site/docs-archive \ --destination-location s3://airflow-docs/docs --exclude amazon,apache.kafka # 覆盖 versioned 目录 breeze release-management publish-docs-to-s3 --source-dir-path /User/pavan/airflow-site/docs-archive \ --destination-location s3://airflow-docs/docs --overwrite # 预览将要发布的文档不实际发布 breeze release-management publish-docs-to-s3 --source-dir-path /User/pavan/airflow-site/docs-archive \ --destination-location s3://airflow-docs/docs --dry-run4. 触发 GitHub Actions 文档发布 workflowworkflow-run publish-docs通过breeze workflow-run publish-docs触发把文档发布到 S3 的 GitHub Actions workflowbreeze workflow-run publish-docs --ref ref --exclude-docs exclude-docs --site-env site-env --refresh-site --skip-write-to-stable-folder docs_packages示例breeze workflow-run publish-docs --ref providers-amazon/1.0.0 --site-env live --refresh-site --skip-write-to-stable-folder amazon apache.kafka各参数含义实现见 workflow_commands.py 的workflow_run_publish参数含义--ref指定 checkout 并构建文档的 Git 引用tag--exclude-docs从发布流程中排除的文档包--site-env站点环境auto/live/staging默认auto按 ref 自动判断 live 或 staging--refresh-site发布文档后是否刷新站点触发 apache/airflow-site 仓库的 workflow--skip-write-to-stable-folder跳过写入 stable 文件夹的文档包--ignore-missing-inventories设置后第三方 intersphinx inventories 无法下载时发布 workflow 不失败。默认缺 inventories 会失败以保证已发布文档的交叉引用完整仅在第三方 inventory 临时故障且必须发布时使用5. 为发布解析约束workflow-run release-constraints触发 GitHub Actions workflow 来解析、发布并 tag 某个发布所属的约束。发布命令本身会触发它该命令主要用于重新生成候选版的约束或在 workflow 出现之前为已切割的发布补产约束breeze workflow-run release-constraints关键行为见workflow_run_release_constraintsworkflow_commands.pystage 仅由--version推导因此不会与它不一致候选版如3.1.3rc1解析时允许apache-airflow-providers-*的预发布版本被投票 wave 的 provider 在 PyPI 上只有rcN版本并提交到独立的 branch保持共享的constraints-X-Y分支不动最终版如3.1.3解析时不允许预发布并提交到constraints-X-Y——正是这一步让已发布约束成为下游所有读取的基线。6. 发布 schema 文件到 S3publish-schemas-to-s3“Publish Docs to S3” workflow 还会把两个生成的 schema 工件发布到同一 docs bucket 的schemas/前缀下站点路径为https://airflow.apache.org/schemas/Execution API OpenAPI 规范schemas/execution-api/version.jsonSupervisor JSON Schemaschemas/supervisor-schema/version.json每个带日期的文件不可变因此命令逐个上传对象且除非给--overwrite已存在的日期会被跳过。发布受包集合门控仅当构建apache-airflow或task-sdk时才发布 schema 文件。用法breeze release-management publish-schemas-to-s3 \ --execution-api execution-api.json \ --supervisor supervisor-schema.json \ --destination-location s3://live-docs-airflow-apache-org/schemas/--destination-location是发布到其下的s3://bucket/schemas/位置每个 schema 写入location/schema-type/version.json。--execution-api与--supervisor至少传一个。7. 检查发布文件完整性check-release-files校验 Apache Airflow SVN 发布目录中所有预期包与工件是否齐备。发布管理员与 PMC 成员在投票前可用它确认所有必需文件包括.asc签名与.sha512校验和都在。支持多种发布类型# Airflow breeze release-management check-release-files airflow --path-to-airflow-svn ~/code/asf-dist/dev/airflow --version 2.8.1rc2 # Task SDK breeze release-management check-release-files task-sdk --path-to-airflow-svn ~/code/asf-dist/dev/airflow --version 1.0.0rc1 # Airflow CTL breeze release-management check-release-files airflow-ctl --path-to-airflow-svn ~/code/asf-dist/dev/airflow --version 0.1.0rc1 # Python client breeze release-management check-release-files python-client --path-to-airflow-svn ~/code/asf-dist/dev/airflow --version 2.10.0rc1 # Providers用 release-date 而非 version breeze release-management check-release-files providers --path-to-airflow-svn ~/code/asf-dist/dev/airflow --release-date 2024-01-01Provider 可指定自定义包列表文件默认packages.txtbreeze release-management check-release-files providers --path-to-airflow-svn ~/code/asf-dist/dev/airflow --release-date 2024-01-01 --packages-file my-packages.txt该命令检查以下文件是否存在源码包.tar.gzwheel 包.whlASF 签名.ascSHA512 校验和.sha512缺少任一预期文件时命令会报告并以非零状态码退出全部齐备时还会给出可用于测试安装的 Dockerfile 片段。8. 约束版本检查constraints-version-check检查当前 Airflow 版本的约束文件是否最新。示例breeze release-management constraints-version-check --python 3.10 --airflow-constraints-mode constraints-source-providers --explain-why六、SBOM 生成任务维护者还可以用 Breeze 生成 SBOM软件物料清单信息。为生成 provider 的 SBOM需要先为其生成 requirements。1. 生成 Provider requirementsgenerate-providers-requirements按指定的 Airflow 版本为选中的 provider 与 Python 版本生成 requirementsbreeze release-management generate-providers-requirements2. 生成 SBOM 信息update-sbom-information得益于为所有 Airflow 版本捕获的约束可以方便地为 Apache Airflow 生成 SBOM。SBOM 包含 Airflow 依赖信息用户可据此判断依赖中的安全问题是否影响自己。SBOM 直接写入 airflow-site 仓库的docs-archivebreeze release-management update-sbom-information3. 构建所有 Airflow 镜像build-all-airflow-images为生成 provider requirements需要预装所有 Airflow 版本的 docker 镜像——用该命令构建每个 Python 版本一个镜像包含所有 2.0.0 兼容的 Airflow 版本breeze release-management build-all-airflow-images4. 导出依赖信息export-dependency-information网站上发布的 SBOM 可转换为电子表格用于分析依赖的安全属性breeze release-management export-dependency-information七、Task SDK、airflowctl 与 Mypy 发行命令1. 准备 Task SDK 发行包prepare-task-sdk-distributionsbreeze release-management prepare-task-sdk-distributions在dist目录生成 Airflow Task SDK 的.whl。默认构建sdistwheel两种可用--distribution-format指定breeze release-management prepare-task-sdk-distributions --distribution-formatwheel传--tag对应 git 实际 tag时除 sdist 外还会生成 source tarball。Task SDK 是 Airflow 3 的任务执行 SDK详见 task-sdk其发行包与 core 共用_prepare_non_core_distributions统一构建链路release_management_commands.py同样支持本地 hatch 或 Docker 内构建并做 sdist→wheel 自检。2. 准备 airflowctl 发行包prepare-airflow-ctl-distributionsbreeze release-management prepare-airflow-ctl-distributions在dist目录生成 airflowctl 的.whl。同样默认构建两种格式breeze release-management prepare-airflow-ctl-distributions --distribution-formatwheel3. 生成 airflowctl changeloggenerate-airflowctl-changelog为 airflowctl 发布生成 RST 格式 changelog并自动前插到airflow-ctl/RELEASE_NOTES.rst。命令读取两个 ref 之间、限定在airflow-ctl/目录内的 git log从 GitHub 拉取 PR 元数据并按 PR 标题前缀分类breeze release-management generate-airflowctl-changelog --previous-release airflow-ctl/0.1.3 --version 0.1.4--current-release默认是HEAD所以无需先创建 tag传--output-file -可改为输出到 stdout 而不修改RELEASE_NOTES.rst。4. 生成 airflow-ctl 发布 Issuegenerate-issue-content-airflow-ctlbreeze release-management generate-issue-content-airflow-ctl发布新版 airflow-ctl 时生成发布跟踪 Issue 内容。airflowctl 完整发布流程见 dev/README_RELEASE_AIRFLOWCTL.md。5. 准备 Mypy 发行包prepare-mypy-distributionsbreeze release-management prepare-mypy-distributions在dist目录生成 Apache Airflow Mypyapache-airflow-mypy类型注解包源码见 dev/mypy的.whl。--distribution-format可选默认是wheelbreeze release-management prepare-mypy-distributions --distribution-formatbothMypy 发行流程详见 dev/README_RELEASE_MYPY.md。八、小结与延伸阅读Breeze 的release-management命令族把 Airflow 生态的发布工作收敛为一条条可复现、可审计的命令覆盖Airflow 核心 / Task SDK / airflowctl / Python Client / Mypy 发行包构建、源码 tarball 与 Helm Chart 包准备、Provider 文档与发行包、约束生成与更新、生产镜像发布与跨硬件合并、PMC 自动化 RC 验证、以及文档与 schema 的多渠道发布airflow-site、S3、GitHub Actions workflow。其中许多命令的完整手工发布步骤仍以各发布指南为准包括dev/README_RELEASE_AIRFLOW.mdAirflow 核心含 “Verify the release candidate by PMC members”dev/README_RELEASE_PROVIDERS.mddev/README_RELEASE_HELM_CHART.mddev/README_RELEASE_PYTHON_CLIENT.mddev/README_RELEASE_AIRFLOWCTL.mddev/README_RELEASE_MYPY.mddev/MANUALLY_BUILDING_IMAGES.md多平台生产镜像构建dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md约束生成加速若想继续了解 Breeze 的其他能力可接着阅读 dev/breeze/doc/10_ui_tasks.rstUI 任务以及 dev/breeze/doc/README.rst文档索引。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考