Skip to content
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

[SR-10665] XCTest should use a module cache under its own control when building tests #352

Closed
beccadax opened this issue May 11, 2019 · 4 comments
Assignees

Comments

@beccadax
Copy link
Contributor

Previous ID SR-10665
Radar None
Original Reporter @beccadax
Type Bug
Status Closed
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s XCTest
Labels Bug
Assignee @beccadax
Priority Medium

md5: d265b5ee13637473454d1b04440413c8

Issue Description:

XCTest appears to build Swift files during its tests without specifying a -module-cache-path argument. This causes it to use a default module cache path in the global /tmp directory. Default module cache paths include a random identifier, but in practice, we've found that these identifiers often collide when Swift CI is running several jobs at once version identifier, but it can't always distinguish between compilers built by different jobs, causing transient failures. Here's a recent example from a Swift CI bot.

It would be better for XCTest to provide an explicit -module-cache-path to a directory inside its own workspace. We've noticed this issue in XCTest's lit configuration, but you may want to look at your build scripts as well. SwiftPM recently made similar changes.

@belkadan
Copy link

Default module cache paths actually deliberately don't contain a random identifier; it's a hash of information identifying the compiler version. That includes the revisions being used, but not necessarily the configuration you built with.

@beccadax
Copy link
Contributor Author

#270

@beccadax
Copy link
Contributor Author

Merged to master.

@beccadax
Copy link
Contributor Author

Haven't seen any XCTest lit failures since.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 9, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants