ci: Run tests before publish

[colin-ho]

Changes Made

Test the built wheel with tests/dataframe before publishing.

Successful run https://github.com/Eventual-Inc/Daft/actions/runs/17419058418

Related Issues

Checklist

• Documented in API Docs (if applicable)
• Documented in User Guide (if applicable)
• If adding a new documentation page, doc is added to docs/mkdocs.yml navigation
• Documentation builds and is formatted properly (tag @/ccmao1130 for docs review)

To fix the problem, add an explicit permissions block at the top level of the workflow file. This block will establish the least privilege required for all jobs in the workflow unless overridden at the job level. For standard CI/CD workflows (build, test, upload/download artifacts, checkout code), contents: read is sufficient. Place the permissions block below the name: and run-name: and above on: on line 3. This provides security and avoids excessive privileges for the GITHUB_TOKEN. No need to modify any individual jobs, as the root-level block applies to all jobs unless overridden.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.61%. Comparing base (058c6cd) to head (2a10320).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5009      +/-   ##
==========================================
+ Coverage   76.47%   76.61%   +0.13%     
==========================================
  Files         934      936       +2     
  Lines      128764   128819      +55     
==========================================
+ Hits        98471    98692     +221     
+ Misses      30293    30127     -166     

see 21 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[greptile-apps]

Greptile Summary

This PR enhances the CI/CD pipeline by adding a quality gate that tests built wheels before publishing them to PyPI and S3. The changes implement optional testing functionality across multiple workflows and improve test robustness to handle missing optional dependencies.

The core enhancement is in the GitHub workflows: build-wheel.yml now includes a test-wheels job that can be optionally enabled via a run_tests parameter. When enabled, this job downloads the built wheels and runs the tests/dataframe test suite across Python 3.9 and 3.11 with both native and Ray runners on Ubuntu. The publish-pypi.yml workflow now sets run_tests: true by default, ensuring wheels are validated before reaching end users. The publish-dev-s3.yml workflow adds the same capability as an optional parameter.

To support reliable testing in CI environments, several test files were updated to handle optional dependencies more gracefully. Files like test_logical_type.py, test_repr.py, and others now use pytest.importorskip('PIL') instead of direct PIL imports, ensuring tests are skipped rather than failing when PIL is unavailable. Similarly, test_creation.py was updated to conditionally define PyExtType and skip tests when PyArrow's PyExtensionType is not available. The integration test configuration in conftest.py was optimized with lazy imports for boto3, numpy, s3fs, and PIL to improve startup performance.

Additional improvements include environment variables to disable analytics and progress bars during CI execution, and enhanced test conditions in test_aggregations.py to ensure proper runner-specific behavior validation. These changes integrate seamlessly with the existing build matrix across different operating systems and architectures while adding this crucial validation step.

Context used:

Rule - Import statements should be placed at the top of the file rather than inline within functions or methods. (link)

_{8 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[kevinzwang]

Could you explain the rationale for running the tests on the built wheel? Is it for checking dependencies? Additionally, wondering why only the dataframe tests.

[colin-ho]

Could you explain the rationale for running the tests on the built wheel? Is it for checking dependencies? Additionally, wondering why only the dataframe tests.

Yeah to make sure we didn't accidentally add dependencies. These tests run on a fresh env with pip installed daft.

A lot of the other tests have testing dependencies. I guess we can add 'importorskip' to all of them, but i thought just dataframe is good enough, better than nothing, for now.