Faiss OSS CI: skip GPU jobs on PRs that touch no GPU-relevant code (#5402)#5402
Closed
mnorris11 wants to merge 1 commit into
Closed
Faiss OSS CI: skip GPU jobs on PRs that touch no GPU-relevant code (#5402)#5402mnorris11 wants to merge 1 commit into
mnorris11 wants to merge 1 commit into
Conversation
Contributor
|
@mnorris11 has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111494465. |
…acebookresearch#5402) Summary: The faiss GitHub Actions CI runs GPU jobs on every pull request (`Linux x86_64 GPU (cmake)`, `Linux x86_64 GPU w/ ROCm (cmake)`, `Linux x86_64 GPU w/ cuVS (cmake)`, and `Linux x86_64 GPU (conda, CUDA 13.2)`). The overwhelming majority of PRs touch only CPU code, yet still have to wait on these long-running GPU builds before they can land. This diff adds a lightweight `changes` job that uses `dorny/paths-filter` to detect whether a PR touches GPU-relevant paths (GPU/cuVS/ROCm sources, any `CMakeLists.txt`, the `cmake/` tree, the GPU conda recipes, and the CI definitions themselves). Each GPU job now gains `needs: changes` and an `if:` guard so it only runs when GPU-relevant code changed — or unconditionally on non-PR events (`push` to `main`, tag builds) so post-merge and release coverage is unchanged. Notes on the approach: - Native `on: ...paths:` cannot do this: it gates the whole workflow, not individual jobs, and is not even honored under `workflow_call` (this file is a reusable workflow invoked from `build.yml`). Per-job gating requires a filter job plus `if:`. - Gating is done at the job level (`if:`), not the workflow level. A job skipped by `if:` reports a `skipped` conclusion, which branch protection treats as neutral/passing — unlike a workflow skipped by `paths:`, which leaves a required check stuck `pending`. - The path globs are intentionally broad and fail safe: a missed path just runs the GPU jobs (wasted time), never silently drops coverage. `**/CMakeLists.txt`, `cmake/**`, and the CI files are included so any build-system or CI change re-enables the full GPU matrix. - The flaky cuVS cmake job is preserved rather than dropped; cuVS regressions are still caught here on GPU-touching PRs, plus nightly and release builds. If we later want it fully non-blocking we can move it to `nightly.yml`. Differential Revision: D111494465
meta-codesync
Bot
changed the title
mnorris11
force-pushed
the
export-D111494465
branch
from
983e38f to
b4247ed
Compare
mnorris11
pushed a commit
to mnorris11/faiss
that referenced
this pull request
Jul 11, 2026
…acebookresearch#5402) Summary: Most PRs touch only CPU or only GPU code, but CI ran the full matrix every time. This adds a lightweight `changes` job (`dorny/paths-filter`) that detects whether a PR touches GPU-relevant or non-GPU paths, then gates each job with `needs: changes` and an `if:` guard: GPU jobs run only on GPU changes, and the CPU variant matrix (AVX/SVE/DD/SVS/conda/etc.) runs only on non-GPU changes. Non-PR events (push to `main`, tags) always run everything, so post-merge and release coverage is unchanged. Globs fail safe: shared build files (`cmake/**`, `CMakeLists.txt`, pyproject, the workflows) count as both GPU and CPU changes, so any build-system change re-runs the full matrix. The same gating is applied across `build-pull-request.yml`, `build-pip.yml`, and `build-pip-gpu.yml`. Differential Revision: D111494465
mnorris11
pushed a commit
to mnorris11/faiss
that referenced
this pull request
Jul 11, 2026
…acebookresearch#5402) Summary: Most PRs touch only CPU or only GPU code, but CI ran the full matrix every time. This adds a lightweight `changes` job (`dorny/paths-filter`) that detects whether a PR touches GPU-relevant or non-GPU paths, then gates each job with `needs: changes` and an `if:` guard: GPU jobs run only on GPU changes, and the CPU variant matrix (AVX/SVE/DD/SVS/conda/etc.) runs only on non-GPU changes. Non-PR events (push to `main`, tags) always run everything, so post-merge and release coverage is unchanged. Globs fail safe: shared build files (`cmake/**`, `CMakeLists.txt`, pyproject, the workflows) count as both GPU and CPU changes, so any build-system change re-runs the full matrix. The same gating is applied across `build-pull-request.yml`, `build-pip.yml`, and `build-pip-gpu.yml`. Differential Revision: D111494465
Contributor
|
This pull request has been merged in 3a7cce4. |
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:
The faiss GitHub Actions CI runs GPU jobs on every pull request (
Linux x86_64 GPU (cmake),Linux x86_64 GPU w/ ROCm (cmake),Linux x86_64 GPU w/ cuVS (cmake), andLinux x86_64 GPU (conda, CUDA 13.2)). The overwhelming majority of PRs touch only CPU code, yet still have to wait on these long-running GPU builds before they can land.This diff adds a lightweight
changesjob that usesdorny/paths-filterto detect whether a PR touches GPU-relevant paths (GPU/cuVS/ROCm sources, anyCMakeLists.txt, thecmake/tree, the GPU conda recipes, and the CI definitions themselves). Each GPU job now gainsneeds: changesand anif:guard so it only runs when GPU-relevant code changed — or unconditionally on non-PR events (pushtomain, tag builds) so post-merge and release coverage is unchanged.Notes on the approach:
on: ...paths:cannot do this: it gates the whole workflow, not individual jobs, and is not even honored underworkflow_call(this file is a reusable workflow invoked frombuild.yml). Per-job gating requires a filter job plusif:.if:), not the workflow level. A job skipped byif:reports askippedconclusion, which branch protection treats as neutral/passing — unlike a workflow skipped bypaths:, which leaves a required check stuckpending.**/CMakeLists.txt,cmake/**, and the CI files are included so any build-system or CI change re-enables the full GPU matrix.nightly.yml.Differential Revision: D111494465