The value that CI brings to developers is the fast feedback loop. If the slowdown of selenium is acceptable to the mobile team, that is their choice. Due to the test pipeline being independent, this does not affect other repositories.
However the gate-and-submit pipeline is blocking. The way mwext-mw-selenium is currently configured makes it participate in the global blocking "mediawiki" queue for the gate-and-submit pipeline.
This job is blocking all merges in all branches of all mediawiki-* repositories.
This is in my opinion unacceptable and unrealistic when compared to the reality of limited time in a day. We can't be spending 20-30 minutes to merge a single change.
I'm recommending immediate disabling of this job in the gate pipeline (test and postmerge are fine). We should also establish a time-based performance budget for how long the blocking queue is allowed to take. We cannot be endlessly adding jobs and filing technical debt to improve it at some point. I propose zero-tolerance and revert of jobs that exceed this budget. We have to draw a line somewhere.
It is then up to the stakeholders of mwext-mw-selenium to iterate further so it abides by this budget. A few different ideas for how to do this:
* Make it faster (< 8 minutes on average). Though unlikely in the short term.
* Make it enforced socially instead of technically. This can be done by having only in the "test" pipeline and the "postmerge" pipelines (which are asynchronous). This way it's still commented to Gerrit and results in V-2 (if the reviewer waits for it). But not in the gate-and-submit pipeline. This way it doesn't block global merges.
* Disable "Dependent Pipeline" functionality of gate pipeline. This functionality has very added value at a very high cost (one repo's merges blocking merges in others). It's nice in theory, but should not have been enabled until our workflow and job configurations are compatible with that paradigm. (T94322)
* Leave dependant gate pipeline in place, but exclude mediawiki-extensions-MobileFrontend from it (by prefixing jobs, thus creating a separate global queue).
* .. something else that results in mobile merges not blocking the global mediawiki gate queue from being blocked for over 10 minutes per commit.