{Build} projectaria_tools - Update cibuildwheel to 2.21.0 in release wheel build workflow - #351
Closed
robertl0 wants to merge 5 commits into
Closed
{Build} projectaria_tools - Update cibuildwheel to 2.21.0 in release wheel build workflow#351robertl0 wants to merge 5 commits into
robertl0 wants to merge 5 commits into
Conversation
… matrix entry to mirror publish workflow (facebookresearch#350) Summary: Explanation: The previous canary recipe diff dropped Python 3.9 from the test-for-build-wheels matrix, but the publish workflow (build-wheels-and-deploy.yml) still ships a cp39 Linux wheel on every release. Without 3.9 in the canary, a future cibuildwheel/runner-image change that breaks 3.9 wheel builds would only be detected on release day. Restores the Python 3.9 ubuntu-latest entry so the canary matrix mirrors the publish matrix exactly: macOS 14 x {3.10, 3.11, 3.12} + ubuntu-latest x {3.9, 3.10, 3.11, 3.12} = 7 cells. Reproducibility: N/A -- matrix-only change. The 3.9 wheel will build with the existing CIBW_BUILD: cp39-* pattern that was previously in this file. Reviewed By: kongchen1992 Differential Revision: D104899027
…est wheel build canary Summary: Explanation: Adds a weekly Monday schedule trigger to the test-only wheel build workflow. With this in place, the canary runs automatically every Monday at 16:00 UTC (8 AM PST / 9 AM PDT) and exercises the cibuildwheel + delocate environment that ships in our PyPI wheels. Detects cibuildwheel/delocate updates, GitHub Actions runner image bumps, and dependency drift before any of these can break a release. The test-only workflow has no publish step, so the schedule cannot accidentally upload to PyPI. Reproducibility: N/A -- schedule trigger only. The first scheduled run will fire on the next Monday after merge; the workflow body itself was validated by an earlier diff. Reviewed By: kongchen1992 Differential Revision: D104902785
…elease wheel build Summary: Explanation: Adds a weekly Monday schedule trigger to the release wheel build workflow as a defense against test/publish file drift. The test-only wheel build workflow (test-for-build-wheels.yml) and this publish workflow are supposed to mirror each other, but in practice they have diverged in the past (Python 3.8 was dropped from this file in 2026-04-02 but stayed in the test file until recently). With a schedule trigger here, drift in this file will be detected weekly instead of waiting for release day. The schedule trigger CANNOT publish to PyPI: the publish-to-pypi job's "Publish to Test PyPI" and "Publish to PyPI" steps are gated on `if: github.event.inputs.deploy == 'test'` and `'prod'` respectively. On a schedule trigger, github.event.inputs.deploy is null, so both conditions are false and no upload happens. The schedule run only exercises the build path. Reproducibility: N/A -- schedule trigger only. The workflow body is unchanged. Reviewed By: kongchen1992 Differential Revision: D104902784
…on workflow_dispatch event for defense-in-depth Summary: Explanation: Adds `github.event_name == 'workflow_dispatch'` to the if-conditions of both publish-to-pypi steps. Today, these steps are gated on `github.event.inputs.deploy == 'test'/'prod'`, which correctly skips publishing on schedule triggers (where inputs.deploy is null). However, `inputs.deploy` could become non-null in the future under other event types -- specifically: - repository_dispatch: external systems can trigger this workflow via API and pass arbitrary payloads. A malformed or malicious payload with `deploy: prod` would publish to PyPI without team oversight. - workflow_call: if this workflow is later made reusable, the calling workflow could pass `deploy: prod` and publish from anywhere. Adding the workflow_dispatch event_name check allowlists publishing to the single intended event type (manual button/API trigger). The contrapositive forms (e.g. `event_name != 'schedule'`) would not protect against repository_dispatch or workflow_call. Zero behavior change today. Defense-in-depth against future event-trigger additions. Reproducibility: N/A -- the publish steps still skip on schedule trigger as before. Manual workflow_dispatch with deploy='test' or 'prod' continues to publish as before. Reviewed By: kongchen1992 Differential Revision: D104904675
…wheel build workflow
Summary:
Explanation:
Brings the release wheel build workflow forward to cibuildwheel 2.21.0 (from 2.17.0, pinned in 2024 due to a macOS dylib delocation issue) and sets MACOSX_DEPLOYMENT_TARGET=14.0 to satisfy the strict wheel-tag check in delocate 0.12.0 (a transitive dependency that newer cibuildwheel pulls). This is the same recipe applied to the test wheel build canary in D104881993, which mirrors what projectaria_private_libs landed in D101880382 + D102733946.
The Python version matrix is unchanged: macOS 14 x {3.10, 3.11, 3.12} + ubuntu-latest x {3.9, 3.10, 3.11, 3.12} = 7 cells. Python 3.9 is intentionally retained (this workflow is the source of cp39 wheels on PyPI).
Note: this changes the macOS install floor for future projectaria-tools wheels to macOS 14 (Sonoma) and later. macOS 11/12/13 are no longer testable on GitHub Actions (macos-13 runners deprecated late 2025), so this matches the testable surface. The macOS install floor change has been live in projectaria-vrs-health-check since April 2026 with no reported user impact.
Reproducibility:
Triggered build-wheels-and-deploy.yml via workflow_dispatch with deploy='build' (no PyPI publish) before requesting review. All 7 matrix cells produced wheels with manylinux tag <X> and macOS arm64 wheels targeting macOS 14. Verified the wheels install in fresh venvs on Ubuntu 22.04 and macOS 14.
Differential Revision: D104908059
Contributor
|
@robertl0 has exported this pull request. If you are a Meta employee, you can view the originating Diff in D104908059. |
Contributor
|
This pull request has been merged in faa2a39. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Explanation:
Brings the release wheel build workflow forward to cibuildwheel 2.21.0 (from 2.17.0, pinned in 2024 due to a macOS dylib delocation issue) and sets MACOSX_DEPLOYMENT_TARGET=14.0 to satisfy the strict wheel-tag check in delocate 0.12.0 (a transitive dependency that newer cibuildwheel pulls). This is the same recipe applied to the test wheel build canary in D104881993, which mirrors what projectaria_private_libs landed in D101880382 + D102733946.
The Python version matrix is unchanged: macOS 14 x {3.10, 3.11, 3.12} + ubuntu-latest x {3.9, 3.10, 3.11, 3.12} = 7 cells. Python 3.9 is intentionally retained (this workflow is the source of cp39 wheels on PyPI).
Note: this changes the macOS install floor for future projectaria-tools wheels to macOS 14 (Sonoma) and later. macOS 11/12/13 are no longer testable on GitHub Actions (macos-13 runners deprecated late 2025), so this matches the testable surface. The macOS install floor change has been live in projectaria-vrs-health-check since April 2026 with no reported user impact.
Reproducibility:
Triggered build-wheels-and-deploy.yml via workflow_dispatch with deploy='build' (no PyPI publish) before requesting review. All 7 matrix cells produced wheels with manylinux tag and macOS arm64 wheels targeting macOS 14. Verified the wheels install in fresh venvs on Ubuntu 22.04 and macOS 14.
Differential Revision: D104908059