【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam18/beam点击查看免费下载Apache Beam 作为面向批处理与流处理的统一编程模型其工程可靠性与 CIContinuous Integration基础设施的建设密不可分。本文以仓库根目录的 CI.md 为骨架结合.github/目录下真实的工作流定义与辅助脚本系统讲解 Apache Beam 如何基于 GitHub Actions 构建一套覆盖多语言 SDK、多 Runner、多操作系统与发布全流程的 CI 体系。读完本文你将能理解 Beam 的 CI 运行分类与触发机制、GCP 凭据的配置要求与权限模型掌握 PreCommit / PostCommit / LoadTest / PerformanceTest 等各类工作流的职责划分并了解自托管 runner 的架构与新增、调试工作流的最佳实践。为什么 Apache Beam 选择 GitHub Actions 作为 CI 平台Apache Beam 的 CI 目标是让这个横跨 Java、Python、Go、TypeScript 等语言驱动 Dataflow、Flink、Spark、Samza、Twister2 等多种执行引擎的项目始终保持可构建、可测试、可发布的状态。为此Beam 将 CI 执行环境统一建立在 GitHub ActionsGHA之上具体背景记录在 CI.md 中与 GitHub 深度集成GHA 与 GitHub 的代码库、工作流生态天然融合易于使用与二次开发从 Jenkins 平滑迁移Beam 最初将部分工作流运行在 GHA 上随后把原本跑在 Jenkins 上的全部工作流迁移过来两种 runner 并存迁移后的工作流统一在预配置的自托管 runner上执行工作流文件名以beam_前缀开头如beam_PreCommit_*.yml、beam_PostCommit_*.yml而 Jenkins 迁移前新增的多数工作流则运行在GitHub 托管的 runner上负责在 Linux / macOS / Windows 多种操作系统上验证行为部分 Linux 任务后来也切换到了自托管 runner。这两种 runner 的完整任务清单、触发短语与状态记录在 .github/workflows/README.md 中它是阅读本仓库 CI 定义时的第一手索引。CI 运行的三种类型PR、合入与定时Beam 的 GHA 任务可分为三类运行run每类运行的目的与执行上下文截然不同这是理解整个 CI 体系的关键。Pull Request Run拉取请求运行贡献者从 fork 提交的 PR 触发的构建是 Beam 构建的主体。这类运行在Fork 仓库的上下文中执行只对 GitHub 资源容器镜像仓库、代码仓库拥有只读权限——这是必要的安全约束因为 PR 中的代码包括 CI 任务定义本身可能由非 committer 修改。其核心目的是检查 PR 是否能够干净构建、测试是否通过、是否已准备好评审与合入。Direct Push/Merge Run直接推送/合入运行由 committer 直接推送或合入 PR 触发的运行在Apache Beam 主仓库的上下文中执行对 GitHub 资源拥有写权限。它的价值在于验证多个 PR 合入后代码是否仍然满足所有断言构建通过、测试全绿——因为某些在隔离状态下各自通过的 PR冲突的改动合在一起可能导致构建或测试失败。Scheduled Run定时运行仅针对master分支的每日定时任务主要目的是检测外部依赖变更对 Beam 代码的影响例如某个传递依赖发布了导致构建失败的新版本并在构建成功后为最新 master 打上nightly-master分支标签。三类运行共享相同的工作流定义但其中的 job 会因运行类别不同而表现得略有差异或直接跳过。许多 job 采用矩阵matrix策略在同一 job 下跑出多种变体例如不同平台、不同 Python 版本这一设计可以从 build_wheels.yml 的三平台 wheel 构建矩阵中直观看到。Google Cloud Platform 凭据配置项与权限模型Beam 的不少 CI job 需要访问 Google Cloud PlatformGCP执行操作相关变量以 GitHub Secrets 形式存储。这些变量在 CI.md 中被完整列出Secret 变量用途示例值GCP_PROJECT_IDGoogle Cloud 项目 IDapache-beam-testingGCP_REGION存储桶与 Dataflow job 所在区域us-central1GCP_TESTING_BUCKETDataflow 测试临时文件存储桶beam-github-actions-testsGCP_PYTHON_WHEELS_BUCKETPython 源码包与 wheel 的存储桶beam-wheels-stagingGCP_SA_EMAIL服务账号邮箱格式通常为nameproject-id.iam.gserviceaccount.com—GCP_SA_KEY服务账号密钥需编码为 Base64 字符串macOS 下可用cat my-key.json \| base64生成—服务账号需要具备以下 IAM 角色Storage Adminroles/storage.adminDataflow Adminroles/dataflow.adminArtifact Registry writerroles/artifactregistry.createOnPushBig Query Data Editorroles/bigquery.dataEditorService Account Userroles/iam.serviceAccountUser这些变量的实际校验逻辑落在 scripts/ci/ci_check_are_gcp_variables_set.sh 中脚本遍历GCP_PROJECT_ID、GCP_REGION、GCP_SA_EMAIL、GCP_SA_KEY、GCP_TESTING_BUCKET、GCP_PYTHON_WHEELS_BUCKET六个变量全部存在时输出gcp-variables-settrue到$GITHUB_OUTPUT否则输出false并告警。依赖 GCP 的 job 都通过needs依赖这一检查 job 的输出来决定是否跳过例如 build_wheels.yml 中的prepare_gcs与upload_wheels_to_gcs都带有if: needs.check_env_variables.outputs.gcp-variables-set true的条件。这正是 CI.md 表格中 Requires GCP Credentials 一栏标为Yes/No的原因凭据存在与否决定相关 job 是否被执行。GitHub 托管 runner 上的核心工作流CI.md 中 GitHub 托管 runner 部分重点介绍了三个工作流它们分别覆盖了 Beam 的 Python 与 Java SDK 的核心测试面。构建 Python 源码包与 wheelbuild_wheels.ymlbuild_wheels.yml 完整串联了从源码包构建到 GCS 分发的流水线各 job 及运行类别见下表Job描述PRPush/Merge定时需 GCP 凭据Check GCP variables检查 GCP 变量是否设置依赖它的 job 以该 job 输出为准是是是是/否Build python source distribution构建 Python 源码包并上传为 artifacts发布分支产物供发布流程使用见 build_release_candidate.sh是是是—Prepare GCS若目标路径已存在则先清空 GCS 目标路径—是是是Upload python source distribution to GCS bucket将源码包上传到该次运行唯一的 GCS 路径—是是是Build python wheels on linux/macos/windows用cibuildwheel在三平台构建 wheel 并上传 artifacts发布分支产物供发布流程使用是是是—Upload python wheels to GCS bucket将 wheel 上传到运行唯一路径并额外上传工作流运行数据—是是是List files on Google Cloud Storage Bucket列出 GCS 上的文件用于验证—是是是Branch repo nightly源码包与 wheel 构建成功后将仓库分支到nightly-master——是—从源码中可以提取几个值得关注的工程细节触发条件该工作流在 pushmaster、release-*分支、v*标签、pull_request限定sdks/python/**、model/**、release/**路径、定时cron10 2 * * *与workflow_dispatch下触发Python 版本矩阵check_env_variablesjob 定义了PY_VERSIONS_FULLcp38-* cp39-* cp310-* cp311-*并区分PR 只跑最高版本、push/cron 跑全量版本的策略wheel 构建矩阵覆盖ubuntu-latest、macos-latest、windows-latest三个平台外加 Linuxaarch64架构通过 QEMU 模拟RC 特殊流程当检测到-RC.形式的标签时工作流会额外构建带 RC 版本的源码包与 wheel并生成sha512校验文件——这些产物正是发布候选验证所依赖的输入GCS 路径唯一性上传路径基于GITHUB_REF、GITHUB_SHA与GITHUB_RUN_ID组合生成GCP_PATH: gs://${{ secrets.GCP_PYTHON_WHEELS_BUCKET }}/${GITHUB_REF##*/}/${GITHUB_SHA}-${GITHUB_RUN_ID}/保证每次运行互不覆盖运行元数据落盘upload_wheels_to_gcs会把GITHUB_WORKFLOW、GITHUB_RUN_ID、GITHUB_ACTOR、GITHUB_EVENT_NAME等环境变量写入github_action_info文件并连同 GitHub 事件文件一起上传便于事后追溯。Python 测试python_tests.ymlpython_tests.yml 聚焦 Python SDK 的正确性验证Job描述PRPush/Merge定时需 GCP 凭据Check GCP variables检查 GCP 变量是否设置是是是是/否Build python source distribution构建源码包并上传 artifacts供Python Wordcount Dataflowjob 使用—是是是Python Unit Tests运行 Python 单元测试是是是—Python Wordcount Direct Runner用 Direct Runner 运行 Python WordCount 示例是是是—Python Wordcount Dataflow用 Dataflow Runner 运行 Python WordCount 示例—是是是Java 测试java_tests.ymljava_tests.yml 与 Python 测试工作流保持同一套分层模式Job描述PRPush/Merge定时需 GCP 凭据Check GCP variables检查 GCP 变量是否设置是是是是/NoJava Unit Tests运行 Java 单元测试是是是—Java Wordcount Direct Runner用 Direct Runner 运行 Java WordCount 示例是是是—Java Wordcount Dataflow用 Dataflow Runner 运行 Java WordCount 示例—是是是两个工作流的pull_request触发路径也有所区分Python 工作流监听sdks/python/**与model/**Java 工作流监听sdks/java/**、model/**、runners/**、examples/java/**、examples/kotlin/**、release/**、buildSrc/**等路径——只有在相关代码变化时才会在 PR 上触发对应语言的测试。发布准备与验证工作流CI.md 还专门列出一组仅通过workflow_dispatch手动触发不参与 PR / Push / 定时运行的发布相关工作流它们把 Beam 的发布流程从切分支到验证 RC全部自动化。Start Snapshot Buildstart_snapshot_build.ymlStart Snapshot Buildjob 会针对apache:master创建 PR并触发一个构建 snapshot 的任务。Choose RC Commitchoose_rc_commit.ymlChoose RC Commit从指定提交出发创建一个发布候选RC并打上带标签的提交。从 choose_rc_commit.yml 可以看到它通过workflow_dispatch接收RELEASE如2.XX.0、RC整数 RC 版本、COMMIT完整 commit SHA等输入并在release-RELEASE分支上执行set_version.sh设置版本后打双标签——主标签vRELEASE-RCRC与带sdks/前缀的 Go SDK 标签因 Go Modules 位于子目录需要前缀标签见工作流内注释对 BEAM-13119 的说明同时提供PUSH_TAG是否推送标签与OVERWRITE是否覆盖已存在标签选项且明确提示若 RC 已构建并对外共享则不要覆盖。Cut Release Branchcut_release_branch.ymlUpdate Master将 master 更新为下一发布版本Update Release Branch则从当前开发版本切出发布分支。该流程的分支演进关系可参考 contributor-docs/images/cut-release-branch.png 的示意master 处于下一迭代 SNAPSHOT同时从当前 SNAPSHOT 拉出release-2.29.0发布分支完整操作步骤见 contributor-docs/release-guide.md。Verify Release Buildverify_release_build.ymlVerify Release Build在 CI 上针对发布分支验证 Gradle 构建的完整生命周期以及全部 PostCommit / PreCommit 测试是发布前对整仓工程质量的总校验。Git Tag Release Versiongit_tag_released_version.ymlGit Tag Release Version通过复制最终发布候选的标签为正式发布版本创建并推送新标签。Run RC Validationrun_rc_validation.ymlRC 验证阶段运行的 job 包括Job描述需 GCP 凭据Python Release Candidate在 PR 上评论以触发 Python ReleaseCandidate Jenkins job否Python XLang SQL Taxi用 DataflowRunner 运行 Python XLang SQL Taxi是Python XLang Kafka用 DataflowRunner 运行 Python XLang Kafka Taxi是Direct Runner Leaderboard用 DirectRunner 运行 Python Leaderboard是Direct Runner GameStats用 DirectRunner 运行 Python GameStats是Dataflow Runner Leaderboard用 DataflowRunner 运行 Python Leaderboard是Dataflow Runner GameStats用 DataflowRunner 运行 Python GameStats是其中Python Release Candidate job 对应仓库中的 run_rc_validation.sh 发布脚本整个发布候选的构建与校验链路可从 release-guide.md 中获得操作指引。自托管 runner 上的 PreCommit / PostCommit 体系从 Jenkins 迁移而来的大量工作流遵循统一的触发约定CI.md 将其总结为下表描述Pull Request RunDirect Push/Merge RunScheduled RunWorkflow DispatchPostCommit否是是是PreCommit是是是是也就是说PreCommit 会在 PR 上运行作为合入门禁PostCommit 则只在合入 master 后与定时任务中运行作为合入后的回归验证。PreCommit 工作流PreCommit 覆盖了 Beam 各语言 SDK 与各 IO 的合入门禁例如beam_PreCommit_Java.yml、beam_PreCommit_Python.yml、beam_PreCommit_Go.yml、beam_PreCommit_RAT.ymlApache RAT 许可证检查、beam_PreCommit_Spotless.yml代码格式、beam_PreCommit_Whitespace.yml空白符检查以及大量beam_PreCommit_Java_XXX_IO_Direct.yml形态的 IO 专项测试覆盖 Kafka、Kinesis、MongoDB、Cassandra、ElasticSearch、Snowflake 等。每个 PreCommit 工作流在 .github/workflows/README.md 中都对应一个触发短语Trigger Phrase例如Run Java PreCommit、Run Python PreCommit (3.8)贡献者只需在 PR 中评论该短语即可重新触发对应检查。以 beam_PreCommit_GHA.yml 为例可以完整看到一套自托管 PreCommit 工作流的典型骨架触发事件push限定.github/**/*.yml路径、pull_request_target限定.github/**/*.yml与 trigger 文件路径、issue_comment、schedule、workflow_dispatch五类显式权限声明由于pull_request_target默认权限是write-all该工作流显式将actions设为write、其余大部分权限设为read这是 CI.md 与 README 反复强调的安全实践并发组concurrency groupgroup: ${{ github.workflow }} ${{ github.event.issue.number || github.event.pull_request.head.label || github.sha || github.head_ref || github.ref }}-${{ github.event.schedule || github.event.comment.id || github.event.sender.login }}配合cancel-in-progress: true保证同一 PR / 同一提交上不会同时堆积多个运行新运行会中断旧运行以节省资源矩阵命名name: ${{ matrix.job_name }} (${{ matrix.job_phrase }})将 job 名与触发短语放入矩阵这是评论触发重跑机制能够定位到具体 job 的前提统一封装通过.github/actions/setup-action完成 checkout 与 rerun 逻辑该 composite action 在pull_request_target/ 评论触发时会显式 fetch 并 checkout PR 的 merge commit见 .github/actions/setup-action/action.yml再通过gradle-command-self-hosted-action执行:beam-test-gha:preCommit这样的 Gradle 测试任务。PostCommit 工作流PostCommit 在合入后与定时任务中运行包含beam_PostCommit_Java.yml、beam_PostCommit_Python.yml、beam_PostCommit_Go.yml及各 Runner 的ValidatesRunner系列Dataflow / Flink / Spark / Samza / Twister2 等、Nexmark基准、Javadoc、Website_Test等。值得注意由于评论触发的方案被发现不可扩展README 中引用了 issue #28909PostCommit 的 PR 内触发改用了临时方案——通过pull_request_target监听.github/trigger_files/workflow_file_name_stem.json路径贡献者若要在 PR 上触发 PostCommit需要在该目录下放置对应名称的 Trigger 文件如beam_PostCommit_Java_DataflowV2.json仓库中 .github/trigger_files/ 已有实际示例。自托管 runner 基础设施CI.md 明确说明迁移过来的工作流都在预配置的自托管 runner上执行因此这些工作流在 Beam 主仓库的常规运行中不再需要 GCP 凭据——凭据只有在换用其他 runner 时才需要。Beam 的自托管 runner 基础设施集中在 .github/gh-actions-self-hosted-runners/ 目录架构上由GCP 支撑使用 Compute Engine 实例模板与实例组承载 Windows Server 2019 与 Ubuntu 20.04 自托管 runner同时用 Kubernetes EngineGKE管理 Linux runner 节点runner token 存放在 GCP Secret ManagerKubernetes 侧配合 HPA / VPA 实现弹性伸缩整体架构可参考 .github/gh-actions-self-hosted-runners/diagrams/self-hosted-runners-architecture.pngRunner Pod 结构GKE 上的 runner Pod 内包含github-actions-ubuntu-runner与docker:20.10.17-dindDinD两个容器通过tcp://localhost:2376通信并挂载gcloud-key、docker-certs-client、dind-storage等存储卷其组成见 .github/gh-actions-self-hosted-runners/diagrams/gh-actions-k8s-runners-pod.png落地实现Linux 部分以 Docker / Kubernetes 部署脚本为主见 self-hosted-linux/Windows 部分提供启动/关闭 PowerShell 脚本见 self-hosted-windows/还包含 runner 自动伸缩的 Cloud Functions 与 Terraform 配置。GitHub Actions 实战提示CI.md 末尾给出了一组对贡献者与维护者都实用的 GHA 操作提示这里结合仓库内容做进一步说明自托管 runner 不需要 GCP 凭据所有迁移后的工作流在预配置自托管 runner 上运行时无需 GCP 凭据只有换用其他 runner 时才需要CI.md 明确说明工作流修改与 PR 检查的时间差如果你修改了工作流定义PR 触发的检查运行中可能不会包含你的最新改动——此时请附上在你自己的 fork 上执行的修改后工作流运行链接供评审者核对在 fork 上调试时可将runs-on: [self-hosted, ubuntu-20.04, main]临时改为runs-on: ubuntu-20.04使用 GitHub 托管 runner且注意 fork 运行无法访问 Beam 主仓库的 secrets详见 .github/workflows/README.md 的Testing new workflows or workflow updates一节macOS runner 超时问题存在已知的 macOS runner 偶发检查失败的 issue遇到时可结合 GitHub Actions 官方文档排查新增工作流的六要素.github/workflows/README.md 要求所有新的 CI 工作流发布与自动化类除外必须包含① 通过矩阵设置的 job 名与触发短语② 一组明确的触发事件③ 显式的 checkout 步骤④ 明确的 GitHub token 权限⑤ 并发组⑥ 评论触发支持——这六点分别对应了上文beam_PreCommit_GHA.yml中展示的骨架。小结Apache Beam 的 CI 体系可以概括为两套 runner、三类运行、两级检查、一条发布链GitHub 托管 runner 负责跨 OS 的构建与 SDK 测试自托管 runner 承载从 Jenkins 迁移而来的海量 PreCommit / PostCommit / LoadTest / PerformanceTest 任务PR、合入、定时三种运行各司其职PreCommit 把守合入门禁、PostCommit 负责合入回归而build_wheels、choose_rc_commit、verify_release_build等工作流则把 Python 产物构建、RC 打标、发布验证等环节连成一条可复现的自动化发布链路。理解这套体系不仅能帮助你读懂 Beam 每个 PR 上那一长串 check 的含义也为在大型多语言项目中设计自托管 CI 提供了可借鉴的范本。参考文件索引CI.mdCI 体系总览本文主体.github/workflows/README.md全部工作流触发短语、状态与清单.github/workflows/build_wheels.ymlPython 源码包与 wheel 构建流水线.github/workflows/python_tests.ymlPython 测试工作流.github/workflows/java_tests.ymlJava 测试工作流.github/workflows/beam_PreCommit_GHA.yml自托管 PreCommit 工作流模板.github/workflows/choose_rc_commit.ymlRC 打标工作流scripts/ci/ci_check_are_gcp_variables_set.shGCP 凭据检查脚本.github/actions/setup-action/action.yml仓库初始化与评论重跑封装 action.github/gh-actions-self-hosted-runners/自托管 runner 基础设施含架构图release/src/main/scripts/发布相关脚本如build_release_candidate.sh、run_rc_validation.shcontributor-docs/release-guide.md发布操作指南赞分享【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam18/beam点击查看免费下载相关推荐Apache Arrow 持续集成CI体系全解析从 GitHub Actions 到 Crossbow 扩展构建Apache Arrow 持续集成CI体系全解析从 GitHub Actions 到 Crossbow 扩展构建 Apache Arrow 是一个面向加速数据工程大数据序列化数据分析RIOT OS 持续集成体系全解从 Murdock 构建集群到 GitHub Actions 工作流RIOT OS 持续集成体系全解从 Murdock 构建集群到 GitHub Actions 工作流 RIOT 是面向物联网的操作系统支持数百种开发板其代物联网嵌入式操作系统实时系统Apache Beam 的 CI/CD 体系基于 GitHub Actions 的 PreCommit/PostCommit 工作流实战指南Apache Beam 的 CI/CD 体系基于 GitHub Actions 的 PreCommit/PostCommit 工作流实战指南 Apache B大数据批处理流处理数据工程上一篇Ant Design Dropdown 语义化 DOM 定制用 classNames 与 styles 精准控制下拉菜单样式下一篇新浪微博图床扩展终极使用指南轻松管理你的在线图片存储创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考