rules_swift

rules_swift copied to clipboard

swift_test targets can now shard their execution using Bazel's standard shard_count test attribute. When Bazel runs a sharded test, it spawns N separate actions in parallel where each shard runs a distinct subset of the tests.

On both Apple and Linux, this is achieved by looking at the shard count and filtering out a subset of tests. This is straightforward on Linux where we generate the test runner. Making this work with Apple's xctest bundle runner would not have been feasible, so we've abandoned that approach and now treat swift_test like any other binary rule: we generate a plain executable (wrapped as an .xctest "bundle" on macOS, but not a Mach-O bundle type binary) and use XCTestSuite.default to access the dynamically discovered tests. From that object, we can recurse down the test suite/test case hierarchy and select the shard's subset to run.

This means we also can no longer use xctest's test filtering, so this change reimplements it manually. This turns out to be an improvement, because we can now use regular expressions to perform the filtering instead of being limited to XCTest's less flexible syntax. Tests will be represented with names of the form ClassName/MethodName, and --test_filter can be a regular expression that matches those.

PiperOrigin-RevId: 606703344 (cherry picked from commit 80cdcccb9ccc205e0e1b68ec863d652d452533c4, 1b1f348bd0e4d37f975a7f92fc135d460ee56a6e, 51b1d1c0a155d6902d7503dfa0f4fcb8cde2bc3c, and bf9019414b00dd0c4e100bf80e8ffc41f6c16ee5)