Repository navigation
Conversation
Test EQL has a selector job, and the other pull request workflows are getting one each. Each workflow's selector must follow the same rules: no path filter on pull_request, one dorny/paths-filter step, an output named after each filter, every job selected on other events, a failure when a filter gives no answer, `if:` conditions that exclude pull_request, and a summary job that needs every other job. workflow-selectors.test.mjs checks those rules for every workflow that has a selector job, found by scanning. It runs the selector's own decision script and the summary job's own check. lib/selector.mjs holds the shared code. It reads a selector job, runs its script, and works out which jobs a pull request runs from the files it changes. It reads dorny's `every` quantifier and brace patterns, which a filter needs to exclude documentation. The parity test now compares a selector workflow's push paths with the union of its selector filters, by what each selects from the tracked files. That replaces Test EQL's written exemption. The dispatch test holds every selector output open, whatever its name.
Three guards check that a workflow's path filter covers what its jobs read: the binding build inputs, the auth binding sources, and the sources the integration suites import. They read `on.push.paths` and `on.pull_request.paths`. Once a workflow has a selector job, its pull request list moves into the selector filter of each job, and those guards would stop checking it. They now read, per job, the lists that decide whether that job runs: the workflow's push and pull_request lists, and the selector filter the job reads. For a workflow without a selector job this is the same two lists as before. They also check only the jobs that build or load the binding, not every job in the workflow.
|
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Comment |
The four integration workflows and the two Prisma E2E workflows used a workflow-level path filter on pull_request. A workflow that a path filter skips leaves its required checks pending, and GitHub's documentation on required status checks says that blocks a merge. Each workflow now runs on every pull request. A `selector` job on a GitHub-hosted runner decides whether the suite runs, and fails when the filter gives no answer. A summary job ends each workflow, and passes when every needed job passed or was skipped. Each filter is the list the pull_request filter had. Those lists are already checked entry by entry against what the suites import and what the binding build hashes, and those guards now read the selector filter. The push lists stay, with their comments, and the parity test compares each one with its selector filter. The suite job's `if:` keeps the fork guard and adds the selector's answer, both written as exclusions of pull_request. A fork pull request still skips, whatever the selector says. integrationSuiteCi.test.ts in protect-ffi cuts the `on:` block so that a `paths:` entry cannot satisfy a claim about a step. It now cuts a `filters:` block too, for the same reason. integration-selectors.test.mjs pins what each selector decides, and the fork guard.
auxesis
force-pushed
the
ci/integration-selector-jobs
branch
from
October 28, 2026 12:59
499b346 to
88820e0
Compare
Contributor
Author
|
Force-pushed: |
This branch has not been deployed
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
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
Six workflows run live suites against CipherStash: the four integration suites and the two Prisma E2E suites. Each used a workflow-level path filter, so it did not start at all on most pull requests. A workflow skipped that way leaves its required checks pending, and GitHub's documentation on required status checks says that blocks a merge.
After this change, each workflow starts on every pull request. A selector job decides whether the suite runs, and a summary job reports the result. Each suite runs for the same changes as before. A pull request from a fork still skips the suite, because a fork run gets no credentials.
This pull request is stacked on #1417. Merge that one first.
Changes
integration-drizzle.yml,integration-prisma-next.yml,integration-protect-ffi.yml,integration-supabase.yml,prisma-example-readme-e2e.yml, andprisma-next-e2e.yml.ubuntu-latest. Its filter is the list thepull_requestfilter had. It fails when the filter gives no answer on a pull request.needs: [selector]. Itsif:keeps the fork guard and adds the selector's answer. Both are written as exclusions ofpull_request.protect-ffitest:src/integrationSuiteCi.test.tscuts a selector'sfilters:block before it searches a workflow for a step. Otherwise a trigger path such as.github/actions/require-cs-secrets/**would satisfy its check for that step.integration-selectors.test.mjspins what each selector decides, and that a fork pull request still skips.Verification
pnpm run test:scripts: 83 files, 1,541 tests passed, 3 skipped.languages/typescript/packages/protect-ffi:vitest run src/lintWiring.test.ts src/integrationSuiteCi.test.tspassed 23 tests.tsc -p tsconfig.test.json,biome lint, andbiome formatpassed on the changed file.actionlint1.7.12 withshellcheck0.11.0 on the six workflows: two findings inprisma-next-e2e.yml(SC2129 and SC2034), at steps this pull request does not change. The base branch has the same two.Related
Review notes
if:on one suite job. A fork pull request must still skip the suite.workflow-paths-filter-parity.test.mjs, these pull requests edit neighbouring lines. The second to merge needs a rebase.