What's the best way to ensure that code hitting the MediaWiki deployment train is good and all our tests are passing before the train cut?
Could this be done organization wise instead of manually for our projects?
How do we move forward with this?
Discuss, ping people and send an email thread with the questions and proposed solutions to discuss more openly.
Time: 2hrs
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | zeljkofilipin | T91669 Make browser tests voting for all repos of WMF deployed code | |||
| Resolved | zeljkofilipin | T55697 [EPIC] trigger browser tests from Gerrit (tracking) | |||
| Resolved | • Jhernandez | T104315 [GOAL]: Set up testing environments that run browser tests on all patches. | |||
| Resolved | Jdlrobson | T100293 [EPIC] Run browser tests against every MobileFrontend/Gather patch | |||
| Duplicate | phuedx | T101865 Ensure tests are green before they hit production | |||
| Resolved | Jdlrobson | T108973 Spike: How do we ensure tests are green before they hit production? |
@bmansurov other projects can change code and break our functionality and they may not be running the same jenkins setup as we do. That would be the case for it I guess.
Let's talk about this, an outcome can be that this is not feasible or the work is not worth it currently and that we'll have to do this manually or check the saucelabs runs on fridays/mondays manually.
That'd be fine, the case is starting the convo and informing the blocked task for resolution.
Moving to next sprint.
Boom! Discussion started on wikitech-l "QA: Holding our code to better standards."
Let's get buy-in and a way forward and call this epic squashed.
To summarise:
https://phabricator.wikimedia.org/T111467 is up for grabs for core commits
Handing over to @greg's team on https://phabricator.wikimedia.org/T111545#1617119 - we should ping as stuff breaks due to its absence to bump up the priority. :)
I think there is little more we can do here so I'm calling this done.