-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Windows] Use a multiroot data file to test (corelibs-)foundation on Windows #80122
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
@swift-ci Please test Windows |
@swift-ci Please smoke test |
3d7ce49
to
6053b15
Compare
@swift-ci Please smoke test |
@swift-ci Please smoke test macOS |
Odd, we are building less in the swift-corelibs-foundation test but it’s still slower. Attaching relevant portions of the build log and running again to see if there’s nondeterminism involved. |
@swift-ci Please test Windows |
1 similar comment
@swift-ci Please test Windows |
6053b15
to
3483edb
Compare
@swift-ci Please test Windows |
1 similar comment
@swift-ci Please test Windows |
3483edb
to
a2e001a
Compare
@swift-ci Please test Windows |
1 similar comment
@swift-ci Please test Windows |
…Windows We currently rebuild swift-syntax, swift-foundation-icu and swift-foundation twice: Once to test swift-foundation and once to test swift-corelibs-foundation. Using a unified build for both projects means that we only need to rebuild them once, saving ~5 minutes.
a2e001a
to
c0a8227
Compare
@swift-ci Please test Windows |
Looking at the performance logs for this PR, I realized that #80082 accidentally changed swift-foundation to be tested in release configuration again. This restores it to be built in debug again. It also saves ~2 minutes in swift-corelibs-foundation through the multiroot data file. It’s less than I would have expected Before this PR:
With this PR (Log):
Running once more to see how stable these timings are. Edit: Timings are stable. |
@swift-ci Please test Windows |
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.
LGTM, but CC @compnerd and @jmschonfeld as well
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.
Should we do the same thing on Linux to keep our test environments consistent between the two platforms?
-Platform $BuildPlatform | ||
-Bin "$ScratchPath" ` | ||
-Platform $BuildPlatform ` | ||
-Configuration $FoundationTestConfiguration ` |
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.
Is $FoundationTestConfiguration
defined somewhere?
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.
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 🤔
We currently rebuild swift-syntax, swift-foundation-icu and swift-foundation twice: Once to test swift-foundation and once to test swift-corelibs-foundation. Using a unified build for both projects means that we only need to rebuild them once, saving ~5 minutes.