-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Fixes SwiftLint support on Xcode Cloud #4485
Conversation
Generated by 🚫 Danger |
f4d436d
to
e2da33e
Compare
e2da33e
to
8de6883
Compare
@@ -71,7 +71,14 @@ extension Configuration { | |||
|
|||
internal var cacheURL: URL { | |||
let baseURL: URL | |||
if let path = cachePath { | |||
|
|||
if ProcessInfo.processInfo.environment["CI"] == "TRUE" { |
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.
CI is a super generic environment variable name. Is there a more reliable way to detect if this is running in an Xcode Cloud environment? I won't want everyone running SwiftLint in their CI to suddenly lose caching.
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.
Calling NSTemporaryDirectory()
will return a new directory every time, effectively disabling caching of linter results. If we do something like this, it should be by disabling caching explicitly.
Yeah we thought of that and the problem is that we can't send any parameters to Xcode Plugins (as you know) and the only other solution would be to introduce another plugin target which explicitly disables caching, what do you think? Is it better to introduce a second SwiftLintPlugin or disable caching entirely only on Xcode Cloud? |
Does Xcode Cloud have any way to persist state across CI jobs at all? If not, then we should find the most reliable way to detect we're running on that platform and disable caching completely. |
Here: https://github.com/realm/SwiftLint/blob/0.50.0-rc.3/Source/swiftlint/Commands/Lint.swift#L53 Could be ignoreCache: noCache || ProcessInfo.processInfo.environment["SWIFTLINT_DISABLE_CACHE"] == "TRUE" |
In theory DerivedData will be cached between builds, however it seems like we don't have write access to that path.
I did some digging and it seems like Xcode Cloud is the only CI setting the variable ignoreCache: noCache || ProcessInfo.processInfo.environment["CI_BUNDLE_ID"] != nil We'd much rather have this working automatically than manually setting an environment value on the Target itself, what do you think? Would it be reliable enough? At least until we get write permissions on the Xcode Cloud VM. |
Xcode Cloud supports setting custom environment variables, so I'd like to propose that users define the
|
Alright, I'll update the PR and also update the README to reflect this change. Thanks for the input! |
You know what, looking at the Xcode Cloud docs again, I think we can be reasonably sure that we're running on Xcode Cloud if all of the following environment variables are set:
So you could extract a function that determines if we're running on Xcode Cloud. If someone or some other CI sets all the same environment variables, then I think it's reasonable to disable caching. |
Good idea, we'll go ahead and fix that. I'm glad we could come up with a solution that disables caching automatically , because then we can remove it later when the environment grants us write access! Ignore my commits, I'll get back with the fix later! I think it's reasonable to have a section in the README about caching not working on Xcode Cloud, what do you think? I also saw that the README is available in a few other languages than English, how do we properly update all of them? |
I don't think this needs a readme entry, and when we update the readme we typically only update the English one, the other ones are occasionally updated by other contributors who speak that language. |
Fixes realm#4484 by checking the process environment for all the expected environment variables set by Xcode Cloud.
afd4b26
to
c2ddb08
Compare
Looks good @JagCesar, thanks for the PR. I made a few small modifications and will be merging once CI is 🟢
|
…e Cloud In Xcode Cloud environment, SwiftLint’s cache cannot be written. When using the SwiftLinkPlugin, there is no way to disable the cache. Previously, a solution was made for the SwiftLint CLI itself where it looks at a set of environment variables (realm#4485). This solution offers a cleaner approach where the plugin itself decides whether it needs to enable or disable the cache based on the `CI_XCODE_CLOUD` environment variable.
) In Xcode Cloud environment, SwiftLint’s cache cannot be written. When using the SwiftLintPlugin, there is no way to disable the cache. Previously, a solution was made for the SwiftLint CLI itself where it looks at a set of environment variables (#4485). This solution offers a cleaner approach where the plugin itself decides whether it needs to enable or disable the cache based on the `CI_XCODE_CLOUD` environment variable. In the long run, SwiftLint should get rid of `isLikelyXcodeCloudEnvironment` entirely. The caller should always decide if caching is possible or not, while SwiftLint itself should be platform-agnostic.
…alm#5287) In Xcode Cloud environment, SwiftLint’s cache cannot be written. When using the SwiftLintPlugin, there is no way to disable the cache. Previously, a solution was made for the SwiftLint CLI itself where it looks at a set of environment variables (realm#4485). This solution offers a cleaner approach where the plugin itself decides whether it needs to enable or disable the cache based on the `CI_XCODE_CLOUD` environment variable. In the long run, SwiftLint should get rid of `isLikelyXcodeCloudEnvironment` entirely. The caller should always decide if caching is possible or not, while SwiftLint itself should be platform-agnostic.
This PR fixes so SwiftLint installed as Xcode Plugin can be used on Xcode Cloud. The problem was that Xcode Cloud doesn't have write access to the
.cachesDirectory
. We solved this by always usingNSTemporaryDirectory()
if we're being run on a CI.This will have the side-effect of doing the same on all CI's, but we couldn't come up with a way to distinguish Xcode Cloud from other CI's.
Solved this together with @westerlund
fixes #4484