Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Cutting CI build times: prebuilt Arrow and build configuration

Đang mở
  • Có gì không ổn?
#799 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
cmake, cpp, github-actions
Lĩnh vực
build-system, ci-cd, performance

Hướng nghiên cứu

Bắt đầu bằng cách đọc các workflow GitHub Actions hiện có, cpp-linter.yml, tệp toolchain của CMake và các phép đo fork được mô tả trong issue. So sánh các đề xuất về thiết lập Arrow, build-flavor, cấu hình Windows, trigger và sccache với ma trận hiện tại. Được xem là hoàn tất khi một tập con các thay đổi đã được thống nhất được triển khai và ma trận build và kiểm thử đầy đủ xác nhận phạm vi bao phủ dự kiến cũng như những cải thiện về thời gian CI.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?
Ngôn ngữ chính
C++
Star
223
Fork
127
Merge trung bình
1 ngày 13 giờ
Pull request đã merge (30 ngày)
28

Chuẩn bị môi trường

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/iceberg-cpp

Tất cả issue của apache/iceberg-cpp

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.