-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Non-darwin test discovery with Swift Build #8722
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Sources/SwiftBuildSupport/PackagePIFProjectBuilder+Products.swift
Outdated
Show resolved
Hide resolved
Locally, I can pass a decent chunk of TestDiscoveryTests on linux. macOS will need a bit of work to skip building the test runner executables, and I expect Windows will need a few tweaks @swift-ci test |
a18182a
to
10bc51d
Compare
10bc51d
to
401a93f
Compare
@swift-ci test |
401a93f
to
3757526
Compare
@swift-ci test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for converting the TestDiscoverTests from XCTest to Swift Testing. I have a couple questions/comments, but nothing blocking.
633a864
to
88ccf4a
Compare
@swift-ci test |
88ccf4a
to
23a8d43
Compare
@swift-ci test |
23a8d43
to
61c3ec0
Compare
@swift-ci test |
Working to address linker failures in swiftlang/swift-build#576 |
@swift-ci test |
61c3ec0
to
8a2f0a2
Compare
@swift-ci test |
8a2f0a2
to
9cfbd82
Compare
@swift-ci test |
9cfbd82
to
e63dc87
Compare
@swift-ci test |
e63dc87
to
70dcd09
Compare
@@ -4106,11 +4106,12 @@ class PackageCommandSwiftBuildTests: PackageCommandTestCase { | |||
throw XCTSkip("SWBINTTODO: Build plan is not currently supported") | |||
} | |||
|
|||
#if !os(macOS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: why are we not executing this test on macOS?
static var buildSystems: [BuildSystemProvider.Kind] = { | ||
if ProcessInfo.hostOperatingSystem == .windows { | ||
// Windows currently fails due to long path handling issues on Windows | ||
return [BuildSystemProvider.Kind.native] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue (blocking): we should execute these tests on Windows and mark each test as withKnownIssue
so we get signal, so we can ensure the test is enabled once the underlying windows path issue is fixed.
Have a looks at Tests/FunctionalTests/TraitTests.swift
for how those tests handle it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only reviewed the tests changes. Although the overcharge is good, we should ensure to run the TestDicoveryTests against SwiftBuild on Windows and use the withKnownIssue
Swift Testing API to essentially mark the test as "expected fail". This will give us signal when the underlying Windows issue is fix, thus prompting the removal of the withKnownIssue
as opposed to having to remember to augment the test.
Still needs a fair amount of work and cleanup, I'll look at breaking off some parts that can land independently. Depends on the larger patch in swiftlang/swift-build#499