I'd written a post on our evaluations of the frameworks. Unfortunately back in the time we had some issues with Cypress that couldn't be resolved at the time. I think there's an existing patch on that.

@Hamza_bin_mubeen11 as mentioned in the above comment wikimedia-previews is maintained on GitHub. Please create an issue there or reach out to us on respective IRC (Zulip) for more help

@WMDE-Fisch thanks for pointing it out. I've changed the task title

In T247312#6658601, @WMDE-Fisch wrote:

In T247312#6656878, @gerritbot wrote:

Change 644314 had a related patch set uploaded (by Harriet Ayugi; owner: Harriet Ayugi):
[mediawiki/extensions/AdvancedSearch@master] Selenium: Target Mediawiki-Docker by default

https://gerrit.wikimedia.org/r/644314

Hej @Harriet sorry to stop you here, but as I understood the last comment by @kostajh, this task is _not_ about changing the default/fallback in the wdio.conf from using the Vagrant settings.

wdio.conf.js should read from that, and if those env variables aren't set then it falls back to settings relevant to Vagrant.

In T247312#6585628, @Addshore wrote:

It might be nice to add a bit of extra logic somewhere in this stack to make this automatically discoverable and configured no matter which one of the commons dev environments you use, rather than switching from one hard coding to another.

@zeljkofilipin yesss this was a task for applicants but this can be assigned to Harriet. We'll have to discuss a bit on the GitHub workflow

@Harriet I have noticed you are yet to complete the application on the Outreachy website. Please do so before the deadline tomorrow. The phabricator task is just a part of the proposal. Until you submit the proposal via Outreachy, we wont be able to consider your application

@Harriet are you running these inside fresh-node? It would also help if you specified what your MacOS version is along with the Node version

In T265011#6533930, @Urbanecm wrote:

Hey, it seems this task asks Outreachy applicants to push a test change to mediawiki/core. Would it be possible to use the sandbox repository instead, to not confuse reviewers about the change's purpose (and reduce the possibility of it getting merged)? Thanks

@Hulya if possible please provide what steps you've used. That would make it easier for me to know where you might have made a mistake

@Hulya have you used the correct Gerrit username

In T265011#6533093, @Rukkykofi wrote:

Hello, I've made the trivial change to the README.md file. I tried submitting the patch with Git Review but I got an error message saying I am prohibited by Gerrit from creating that patch

I'd love to be added to the club. I'll soon be publishing an article(possibly next week)

In T262438#6447891, @Umherirrender wrote:

Both rules are added with ESLint 7.3.0

package-lock.json point to eslint 7.7.0, that sounds fine.

npm ci is shown in the results

Not sure what happens

In T256626#6352438, @Krinkle wrote:

Upstream advertises the sync mode and that is how most people use it.

I looked into async mode as I suspected the Fibers layer might be behind the slowness, but it wasn't the root cause (the root cause was badly written MW tests).

What problem are we looking to solve by changing to async mode?

@zeljkofilipin I am tentatively marking this as Invalid in favour of the recent change: 603933

In T256626#6328478, @Krinkle wrote:

See also:

• T234002: Make MediaWiki Wdio tests less slow (Sept 2019)
• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/539931

In October as part of T234002 and https://gerrit.wikimedia.org/r/539865 I explored using the wdio-async mode but abandoned the idea. From what I can tell, wdio-sync is the only well-understood and supported mode in upstream for wdio. Without it things get quite confusing, fall apart somewhat, and the code doesn't become better, either.

What I did do, is remove all use of browser.call() which was the only publicly exposed usage of Fiber in our code (in favour of native async-await).

This means we no longer use Fiber to weirdly pause execution and wait for our own promises and async code. It is however still used by wdio internally to make browser.goto(), and $() and waitFor and all other wdio commands appear synchronous which is by design and hard to avoid.

Has upstream Wdio decided to make async the default recommended, advertised and documented mode for all examples etc?