The VisualEditor and ULS MediaWiki extensions have recently been blessed with QA browser tests. We would need them to be in the Contint Jenkins and triggered by Zuul whenever a patchset is submitted as well as in the gate-and-submit pipeline.
That needs several step:
Version: wmf-deployment
Severity: enhancement
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add experimental mwext-mw-selenium-jessie | integration/config | master | +10 -0 |
We will go with ULS first since we have a good experience interacting with the i18n team and they are in European timezone just like Zeljko and I.
See also the Wiki page https://www.mediawiki.org/wiki/Continuous_integration/Browser_tests
The Jenkins jobo template in https://gerrit.wikimedia.org/r/#/c/86868/ would let us trigger tests.
Quick status update:
I am focusing this week on integrating Parsoid daemon in Jenkins
This is no more a top priority. We have most browsertests run twice per day instead.
We will eventually managed to get them added in Gerrit, but there is a bit more work that needs to be done first.
(In reply to Antoine "hashar" Musso from comment #6)
This is no more a top priority. We have most browsertests run twice per day
instead.We will eventually managed to get them added in Gerrit, but there is a bit
more work that needs to be done first.
What's the status of this? Are there any projects that have browser tests triggering on each change (even if non-voting)?
If not, can you outline the blockers?
(In reply to Matthew Flaschen from comment #7)
<snip>
What's the status of this? Are there any projects that have browser tests
triggering on each change (even if non-voting)?If not, can you outline the blockers?
It is not hold, mostly because we lack resources to do the integration / make them faster. On top of my head:
Feel free to take the leadership. Zeljkof and Nik Everett would be able to assist. I can offer reviews / guidances as well.
Per a discussion we had in the Releng weekly checkin, triggering browser tests from Gerrit would need the disposable VMs. We would also need to setup MediaWiki and the required backend services such as Parsoid (and more as needed).
I have closed a few tasks that were requesting browser tests to be triggered on patch proposal. There is no point in keeping them open until we are actually ready to trigger such jobs.
The description is a little confusing. Does VisualEditor do this already? I can't see the selenium job on a per commit basis....
For mediawiki/extensions/VisualEditor no browser tests are run for patch upload nor merge, so it probably still needs to be done, possibly also for a few other closed blockers.
@dduvall made it possible to trigger selenium tests when a new patchset is triggered which unblocked a few tasks.
Originally we had this blocked on T47499 which comes from Bugzilla and was the parent tracking task / epic for the Continuous-Integration-Scaling project. It has progressed and we are not so far from having the jobs run on Nodepool. That is T137112: migrate mwext-mw-selenium to Nodepool instances which is more specific than the legacy epic task and better reflect the intention.
Change 341506 had a related patch set uploaded (by hashar):
[integration/config] Add experimental mwext-mw-selenium-jessie
Change 341506 merged by jenkins-bot:
[integration/config] Add experimental mwext-mw-selenium-jessie
Have to make the following extension to trigger the job on patchset proposal:
CentralAuth
CentralNotice
Math
PageTriage
WikiLove
As far as I know this is resolved a long time ago. Please reopen if there is anything left to be done.