Cutting CI build times: prebuilt Arrow and build configuration
維護者通常 2 天內回覆
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
- Issue 類型
- 重構
- 描述清晰度
- 需要釐清
- 活躍度
- 冷清
- 技術堆疊
- cmake, cpp, github-actions
- 領域
- build-system, ci-cd, performance
研究方向
先閱讀現有的 GitHub Actions 工作流程、cpp-linter.yml、CMake 工具鏈檔案，以及 issue 中描述的 fork 測量結果。將 Arrow 設定、build-flavor、Windows 設定、觸發程序和 sccache 提案與目前的矩陣進行比較。當一組已議定的變更完成實作，且完整的建置與測試矩陣確認預期的涵蓋範圍和 CI 時間改善時，即表示完成。
由索引模型根據 Issue 內容生成。
描述
I have some CI changes I'd like to propose. They go a bit deeper than the recent caching work, so I wanted to open an issue first to align on direction before pursuing any of them. The pieces below are independent; taking forward only some of them works fine.
Resolving Arrow from conda-forge
Eleven jobs build the vendored Arrow and Parquet from source, but the toolchain already prefers a prebuilt one (the FetchContent declaration uses FIND_PACKAGE_ARGS); CI just never installs one. Installing libarrow and libparquet from conda-forge with setup-miniconda (ASF allowlisted) takes that compile out of each leg:
| Test leg | Build targets | Cold build step |
|---|---|---|
| Ubuntu | 951 to 606 | 21 to 16 min |
| macOS | 946 to 602 | 11 to 8 min |
| Windows | 900 to 578 | 47 to 35 min |
(fork measurements; times vary with runner load, target counts don't; the AWS, SQL catalog, sanitizer, and linter legs shrink similarly)
It is also most of our cache pressure: one push to main saves around 10 GB of sccache entries, more than the repository's 10 GB limit by itself, so eviction ends up deleting entries that have no newer replacement. Over the past week about every third push to main rebuilt at least one leg from scratch. With prebuilt Arrow, and without debug info that nothing in CI reads, saves drop under 3 GB.
Coverage holds: the AWS leg keeps building the bundled AWS SDK from source, the Meson legs don't use Arrow, and the sanitizer leg passes against the non-instrumented Arrow. The conda pin would track the version in the toolchain file and bump in the same PR.
Building one library flavor per leg
CI builds with ICEBERG_BUILD_STATIC and ICEBERG_BUILD_SHARED both ON, and the two targets compile the same sources twice (the shared build adds the export define and hidden visibility, so objects can't be reused). The tests link one flavor, so building one roughly halves what a leg compiles of our own code. A static-only fork run passes the full build and test matrix; one leg could keep both ON to keep both exercised.
Windows: build Debug like the other legs
The Unix test legs build Debug; Windows builds Release and has been the slowest leg fairly consistently. MSVC Debug needs embedded debug info (/Z7 via CMP0141) for sccache to cache the objects, and that combination is green on a fork. Windows is currently the only Release build in CI, though, so this is partly a question of what the matrix should cover.
Two smaller cleanups
The test workflows trigger on both push (all branches) and pull_request, and the concurrency groups key on different refs per event, so a branch pushed here with an open PR runs everything twice. Scoping push to main, as cpp-linter.yml already does, drops the duplicates and keeps the post-merge runs that seed the caches. Separately, the sccache steps are copy-pasted across nine jobs in five workflow files; a composite action under .github/actions/ would hold them (and the conda setup) in one place.
Questions
- Is conda-forge acceptable as a source of prebuilt Arrow in CI, and how would you want the version pin maintained?
- Single flavor on the test legs: which one, and is it enough to keep one leg building both static and shared?
- Windows on Debug: fine, or should the matrix keep a Release leg?
- Any concerns with the composite action or the push trigger scoping?
- 主要語言
- C++
- 星號
- 228
- 分支
- 136
- 平均合併
- 5 天 19 小時
- 30 天內合併 PR
- 53
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
apache/iceberg-cpp 的其他 Issue
-
bug: TableMetadataBuilder::RemoveSchemas leaves removed ids in the schema index可能已有人在做 @LuciferYang 於 3 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
apache/iceberg-cpp#1011 ·
維護者通常 2 天內回覆
-
難度 5/5 一週以上 新手友好度 12/100
apache/iceberg-cpp#1027 ·
維護者通常 2 天內回覆
-
bug: gzip table metadata is neither written nor detected as gzip可能已有人在做 @LuciferYang 於 3 天前認領。 未關閉
難度 3/5 1-2 天 新手友好度 66/100
apache/iceberg-cpp#1013 ·
維護者通常 2 天內回覆
-
難度 4/5 3-5 天 新手友好度 35/100
apache/iceberg-cpp#1000 · 2 則留言 · 1 個 reaction ·
維護者通常 2 天內回覆
-
難度 5/5 一週以上 新手友好度 8/100
apache/iceberg-cpp#988 · 2 則留言 ·
維護者通常 2 天內回覆
查看 apache/iceberg-cpp 的全部 Issue
相似的 Issue
-
category:port-update
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 2 天內回覆
-
improvement ui
難度 2/5 1-3 小時 新手友好度 72/100
ihhub/fheroes2#11062 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 74/100
維護者通常 1 天內回覆
-
enhancement question
難度 2/5 1-3 小時 新手友好度 72/100
DarkStarSystems/pcons#224 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 77/100
LizardByte/Sunshine#5953 ·
維護者通常 1 天內回覆