Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions utils/build.ps1
Original file line number Diff line number Diff line change
Expand Up @@ -2824,12 +2824,17 @@ function Build-Foundation {
}

function Test-Foundation {
$ScratchPath = "$BinaryCache\$($BuildPlatform.Triple)\FoundationTests"

# Foundation tests build via swiftpm rather than CMake
Build-SPMProject `
-Action Test `
-Src $SourceCache\swift-foundation `
-Bin "$BinaryCache\$($BuildPlatform.Triple)\CoreFoundationTests" `
-Platform $BuildPlatform
-Bin "$ScratchPath" `
-Platform $BuildPlatform `
-Configuration $FoundationTestConfiguration `
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is $FoundationTestConfiguration defined somewhere?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, defaults to debug:

.PARAMETER FoundationTestConfiguration
Whether to run swift-foundation and swift-corelibs-foundation tests in a debug or release configuration.
...
  [ValidateSet("debug", "release")]
  [string] $FoundationTestConfiguration = "debug",

Should we do the same thing on Linux to keep our test environments consistent between the two platforms?

I had thought we were, but... apparently not 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of Debug does scare me a bit - we release in release mode, not debug mode, and the optimizations can introduce issues (and was in fact how we learnt about CFString bridging failures). I would recommend that we test in release mode only. However, the shared build is a good idea.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that we decided in #80076 that we want to test Foundation in debug during PR testing and in release during the nightly jobs. You just accidentally reverted the change for CoreFoundation in #80082 (note that swift-foundation still passed FoundationTestConfiguration).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, it would be okay to test in CI with debug and nightlies with Release (I actually would prefer that). I just don't see how we control that for the nightlies.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nightlies are currently passing through release, eg. https://ci-external.swift.org/job/swift-main-windows-toolchain/1517/ has:

... utils\build.ps1 ... -FoundationTestConfiguration release

Though it also has -Test swift,dispatch,xctest,lldb, so they're not actually being run...

--multiroot-data-file "$SourceCache\swift\utils\build_swift\resources\SwiftPM-Unified-Build.xcworkspace" `
--test-product swift-foundationPackageTests

Invoke-IsolatingEnvVars {
$env:DISPATCH_INCLUDE_PATH="$(Get-SwiftSDK $BuildPlatform.OS)/usr/include"
Expand All @@ -2841,10 +2846,12 @@ function Test-Foundation {
Build-SPMProject `
-Action Test `
-Src $SourceCache\swift-corelibs-foundation `
-Bin "$BinaryCache\$($BuildPlatform.Triple)\FoundationTests" `
-Bin "$ScratchPath" `
-Platform $BuildPlatform `
-Configuration $FoundationTestConfiguration `
-j 1
--multiroot-data-file "$SourceCache\swift\utils\build_swift\resources\SwiftPM-Unified-Build.xcworkspace" `
--test-product swift-corelibs-foundationPackageTests `
-j 1 # Running parallel causes a non-deterministic crash in CI only, see https://github.com/swiftlang/swift/issues/83606
}
}

Expand Down

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.