-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Run Xcode 15 in CI and skip or disable tests that fail #21921
Conversation
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
I found the following issue when testing on Xcode 15 with the new iOS SDK: #21649 (blocker). There may be more issues of a similar kind. I'll require a bit more effort to migrate to Xcode 15 because it also means migrating to iOS 17, which the app currently doesn't (fully) support. |
Thanks @kean 👍 I subscribed to the issue. I also created an Xcode 15 and iOS 17 project in this repo as a quick way to collect and monitor progress on this kind of issues. Feel free to add to it, thanks! |
2dec694
to
615bffb
Compare
var wkCookieStore = WKWebsiteDataStore.nonPersistent().httpCookieStore | ||
var wkCookieStore: WKHTTPCookieStore! |
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.
The value is being assigned in setUp
. It's best to do it like that anyway, so we get a fresh one for every test.
Thanks @pachlava for having a look at the UI tests! 🙌 I'll share here a summary of an internal conversation for visibility: Sergiy noticed that the UI tests are super slow and, because of the slowness, more flaky and prone to fail. (Talk about selective attention, I looked at every single CI build but was only focused on the unit tests and was totally oblivious to how long the UI tests took!) The UI tests alone can now take more than 2 hours to run, that's too long. Unfortunately, this is a known performance issue with Xcode 15 in CI for which there doesn't seem to be a fix yet. Given the performance implications, I see only two options:
As much as it pains me, I think we might need to disable the UI tests in CI. Nothing should stand in the way of fixing user issues. But before doing that, it is also possible that our new M1 CI infra will help with this, based on some of the discussion in the link above and on this forums thread Apple Silicon hardware fairs better. That's not surprising, of course, in terms of raw performance, but there might be something structural going on there, too. cc @jkmassel |
I'll add one more potential option for consideration: run UI tests once a day and deliver a report to the team in case they fail. This will alleviate 50%+ of the pressure from the CI. If it's currently feasible to run UI tests for every build, it means there are not enough of them. |
I'd like to see how this performs on Apple Silicon – it's great that this PR targets I'd be surprised if the performance issues hit us too badly there, from the thread it seems like it's mostly folks who are using Rosetta to run their tests, but I didn't read in-depth. If the tests continue to take an unacceptably long amount of time we can subdivide them further – UI tests are pretty parallelizable. If none of that works, I'd really like to dig into the tests and find out exactly what they're doing, and if this behaviour can be replicated locally – maybe it's something to do with running under a VM? We've seen enormous instability with Xcode 15.0 for Tumblr, so the idea that performance on Intel is somehow compromised in that version isn't too surprising. The good news is that Apple Silicon made an enormous difference there, so hopefully it will here too? I'd very much like to avoid turning off a test suite unless we're left with no other option – and running it on some kind of schedule is essentially turning it off. Every time we've tried it we've ended up in a situation where the tests are broken the majority of the time, so even legitimate failures are dismissed as flakiness. If we can't run a test on every PR, that test isn't worth having. And if we need more capacity to run those tests, we'll add it – computers are cheap, people's time is expensive, so we run the tests – as often as we can. |
@kean 👋 The issue with UI tests after upgrade to Xcode 15 is not the slowness alone, it's the fact that slowness causes timeouts, resulting in them always failing. One alternative is running them locally against |
The current UI test suite has only 35 tests, which is not a lot of tests tbh, and it already overloads the CI. From the developer side, if it takes more than 10 minutes, I'd say it shouldn't run on every push or it will hinder the development flow and works against short-lived branches and TBD.
How long does it take to run the tests on M2/M3 locally? I've yet to run the tests locally because you need a Java runtime. I begrudgingly installed it, ran
That's how it's traditionally been done, otherwise, it sets the wrong incentives. The incentive should be to allow the automation team to create as many UI tests as possible and not worry about their performance as long as it takes no more than 8-12 hours to run the entire suite. |
Thank you for making the change @pachlava! Also I agree with you that we could probably stop running the tests on iPad since it's extremely slow and tests keep failing because of time-outs, and keep it iPhone only for the time being. But I also wonder if this slowness is only seen on CI or will it be seen by actual users on a slower network as well after this change? |
@jostnes, from my understanding of the issue, this is related to virtualization that is used on CI (affects both BK and CircleCI). It's not related to the network speed. |
…ess-mobile/WordPress-iOS into mokagio/fix-code-15-tests
@@ -29,7 +29,7 @@ public class PasswordScreen: ScreenObject { | |||
@discardableResult | |||
public func proceedWithValidPassword() throws -> LoginEpilogueScreen { | |||
try tryProceed(password: "pw") | |||
|
|||
app.dismissSavePasswordPrompt() |
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.
@jostnes I'm surprised by this. tryProceed(password:)
already calls it.
Did it make a difference or is it an experiment?
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.
oh yeah, this has been removed, i overlooked this earlier, this was also the reason the test took a longer time to complete (as it was doing it twice, the second time completely unnecessary 😅)
@@ -20,7 +20,5 @@ | |||
<string>????</string> | |||
<key>CFBundleVersion</key> | |||
<string>1</string> | |||
<key>NSPrincipalClass</key> | |||
<string>${PRODUCT_NAME}.TestObserver</string> |
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.
@jostnes I'd recommend keeping this setup and skipping the executeWithRetries(disableAutoFillPasswords)
in testBundleWillStart
from TestObserver
.
I'm saying this because it's easier to find the TestObserver
setup in the code than in this Info.plist
and hopefully we'll be able to go back to that setup when Apple fixes their Simulator bug (assuming my theory about it being a simulator bug is correct)
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.
yup, this is a temporary removal to save testing time and skip the part where the test tries to turn it off and fails every time because of the simulator bug. this will be re-added before merging.
A bit of an underwhelming PR, where instead of fixing things, I work around failures by disabling tests 😞 In my defense, there doesn't seem much we can do about how the existing implementation of the problematic tests behaves with the iOS 17 SDK.
I thought I'd put this up as a starting point. The unit tests passed in the draft PR. Merging would at least let us officially use Xcode 15.0.1 as development toolchain, so that we can move on to fixing things and find new issues to tackle.
Open to suggestions on how to update the failing code.
Regression Notes
PR submission checklist:
RELEASE-NOTES.txt
if necessary. N.A.UI changes testing checklist: Not a UI PR.