add mac arm ci automation

[sklarsa]

Summary by CodeRabbit

• Chores
  • Updated CI/CD pipeline matrix configuration to support testing on macOS 14 and latest macOS versions.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

A CI pipeline configuration updates the Azure Pipelines matrix by renaming the mac entry to mac-latest and adding a new mac-14 entry with macos-14 image specification.

Changes

Cohort / File(s)	Change Summary
Azure Pipelines Matrix Update ci/run_tests_pipeline.yaml	Renamed mac matrix entry to mac-latest; added new mac-14 entry with macos-14 image for expanded macOS version testing

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 The matrix hops to and fro,
Mac-latest steals the morning glow,
Fourteen joins the testing spree,
Each pipeline config fills with glee!
More macOS versions to test, hooray! 🎉

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'add mac arm ci automation' directly relates to the main change: adding a new mac-14 matrix entry for ARM-based macOS CI automation in the Azure Pipelines configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/test-macos-arm.yaml (1)

31-40: Consider extracting Rust and toolchain setup to a reusable workflow.

Both jobs install Rust identically (lines 31–34 and 84–87). This duplication can be reduced by extracting the common setup steps into a reusable workflow or a composite action, improving maintainability.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3cd70bf and 8594de5.

📒 Files selected for processing (1)

• .github/workflows/test-macos-arm.yaml (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: amunra
Repo: questdb/py-questdb-client PR: 120
File: ci/run_tests_pipeline.yaml:85-85
Timestamp: 2025-11-28T17:46:34.703Z
Learning: In the py-questdb-client repository, Python version testing is handled by cibuildwheel configuration in pyproject.toml. The ci/run_tests_pipeline.yaml pipeline is specifically for testing against various numpy versions, not for comprehensive Python version coverage.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (15)

• GitHub Check: questdb.py-questdb-client-release (cibuildwheel windows_i686)
• GitHub Check: questdb.py-questdb-client-release (cibuildwheel windows_x86_64)
• GitHub Check: questdb.py-questdb-client-release (cibuildwheel macos_x64)
• GitHub Check: questdb.py-questdb-client-release (cibuildwheel linux_x64_cpython_musllinux)
• GitHub Check: questdb.py-questdb-client-release (cibuildwheel linux_x64_pypy)
• GitHub Check: questdb.py-questdb-client-release (cibuildwheel linux_x64_cpython_manylinux_x86_64)
• GitHub Check: questdb.py-questdb-client-release (cibuildwheel start_linux_arm64_agent_aws)
• GitHub Check: questdb.py-questdb-client-tests (Building and testing on windows-msvc-2019)
• GitHub Check: questdb.py-questdb-client-tests (Building and testing on mac)
• GitHub Check: questdb.py-questdb-client-tests (Building and testing on linux-qdb-master)
• GitHub Check: questdb.py-questdb-client-tests (Building and testing on linux-old-pandas)
• GitHub Check: questdb.py-questdb-client-tests (Building and testing on linux)
• GitHub Check: questdb.py-questdb-client-tests (Building and testing TestsAgainstVariousNumpyVersion2x)
• GitHub Check: questdb.py-questdb-client-tests (Building and testing TestsAgainstVariousNumpyVersion1x)
• GitHub Check: Test numpy compatibility (3.11, 2.0.0)

🔇 Additional comments (4)

.github/workflows/test-macos-arm.yaml (4)

51-51: Verify that JAVA_HOME_17_ARM64 is available on macOS-13-xlarge ARM64 runners.

The environment variable JAVA_HOME_17_ARM64 may not be available on this runner. Please confirm it exists or consider using an alternative approach to set JAVA_HOME. You can check GitHub's documentation or test this in a workflow run to verify availability.

---

92-93: Verify the uv run --python python syntax is correct.

The command uv run --python python may not work as intended. The --python flag typically requires a specific path, version identifier, or interpreter name that uv can resolve. Verify that this selects the correct Python version or use an explicit path (e.g., --python python3.10).

---

92-93: The numpy compatibility test only runs a single test class.

The test command runs only TestBufferProtocolVersionV2 instead of the full test suite. If this is intentional for targeted numpy validation, this should be documented in a comment. If it's an oversight, consider running the full test suite with the numpy version matrix.

---

36-40: Inconsistent toolchain setup between jobs.

The test job installs Cython and uses python3 proj.py test, while test-numpy-compat skips Cython and uses uv run. Clarify whether Cython is required for the numpy compatibility tests or if the different invocation methods serve different purposes.

Also applies to: 89-93