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.
Jul 1 2021
Mar 29 2021
Mar 22 2021
@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
Dec 4 2020
Dec 3 2020
Dec 1 2020
@WMDE-Fisch thanks for pointing it out. I've changed the task title
Change 644314 had a related patch set uploaded (by Harriet Ayugi; owner: Harriet Ayugi):
[mediawiki/extensions/AdvancedSearch@master] Selenium: Target Mediawiki-Docker by default
wdio.conf.js should read from that, and if those env variables aren't set then it falls back to settings relevant to Vagrant.
Nov 26 2020
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.
Nov 25 2020
Nov 24 2020
@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
Oct 30 2020
@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
Oct 20 2020
Oct 15 2020
Oct 11 2020
@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
Oct 10 2020
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
Oct 9 2020
@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
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
Oct 8 2020
Oct 7 2020
Oct 5 2020
I'd love to be added to the club. I'll soon be publishing an article(possibly next week)
Sep 23 2020
Sep 18 2020
Sep 15 2020
Sep 11 2020
Sep 10 2020
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
Sep 9 2020
Sep 8 2020
Sep 3 2020
Aug 26 2020
Aug 25 2020
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?
Jul 30 2020
Jul 23 2020
- T234002: Make MediaWiki Wdio tests less slow (Sept 2019)
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?