Closed giamir closed 8 months ago
Name | Link |
---|---|
Latest commit | a8a980da8ba3967da9da60d5f927a06b5612528d |
Latest deploy log | https://app.netlify.com/sites/stacks/deploys/65c0b908b0fb5c00085ddc98 |
Deploy Preview | https://deploy-preview-1626--stacks.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
@giamir I haven't given this PR a thorough review, but I wanted to let you know the results of my local run.
Besides visual regression tests, everything seemed to run smoothly. For the visual tests, I had 8 reported timeouts which all looked something like this:
lib/components/badge/badge.visual.test.ts:
β Browser tests did not start after 20000ms You can increase this timeout with the testsStartTimeout option. Check the browser logs or open the browser in debug mode for more information. (failed on Chromium and Webkit)
β The browser was unable to create and start a test page after 30000ms. You can increase this timeout with the browserStartTimeout option. (failed on Firefox)
Error: The browser was unable to create and start a test page after 30000ms. You can increase this timeout with the browserStartTimeout option.
at Timeout._onTimeout (/app/node_modules/@web/test-runner/node_modules/@web/test-runner-core/dist/utils/async.js:14:20)
at listOnTimeout (node:internal/timers:569:17)
at process.processTimers (node:internal/timers:512:7)
After this first run, I ran it again and had a similar outcome. If you'd like I'm happy to help you debug this in whatever way might help @giamir
@dancormier Running visual regression tests requires a significant amount of resources (since 3 browsers are running in parallel multiple tests). The good thing is that all the failures you get are timeouts. This in my opinion means that you have not allocated enough resources to the docker engine in your machine (or more unlikely that you need a more powerful machine). π
I will start by tweaking the docker settings. Here are mine as a reference:
Let me know if this helps otherwise we might want to tune down a bit the parallelism settings in WTR (ideally not though because it will inevitably slow the test run).
@dancormier Given that running individual tests in parallel did not yield much benefits and created more flakiness I opted to simplify the setup and keep only the parts that are helping to keep the suite stable. In particular I removed the semaphore and the bespoke visual test framework and I kept the retry mechanism to guarantee stability. I also set the number of concurrent browsers to 3 because it speeds up tests also in CI. If you have issues in your machine with that setting I am happy to set the number only in the dedicated wtr-ci config file.
Despite the 77 file changes this PR doesn't change a lot - most of those changes are references to the new test-utils files. The file that deserves a proper review is visual-test-utils.ts
. The rest of the stuff is just cosmetic.
Thank you in advance for the review.
STACKS-512
Test run seems to very stable now (see here).
@dancormier When you get a second (not urgent) can you test in your machine and give feedback? Thanks