Page MenuHomePhabricator

split phpcs in voting and non-voting sniffs
Closed, DeclinedPublic


It makes no sense, when there is phpcs checking and the result is non-voting. Nobody is looking at that output. You can disable it and save the resources.

Some already fixed sniffs are reintroduced into core, due to nobody looking at the sniff output.

Please spilt the phpcs in a voting step and a non-voting step. When a sniff pass all files in core, than moving it from non-voting to voting to avoid that it came back.

It is a hard job and will take some time to fix all sniffs or to configurate it that all will pass, so do it step by step and make the already fixed things voting to avoid merging of that.


Version: wmf-deployment
Severity: enhancement



Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:14 AM
bzimport set Reference to bz46500.
bzimport added a subscriber: Unknown Object (MLST).

We could pass '-n' to phpcs, that will ignore any warning. Then fix all remaining errors and enforce their resolution by making that job a blocker.

Change 81183 had a related patch set (by Hashar) published:
new phpcs jobs for mediawiki/core

Change 81183 merged by jenkins-bot:
new phpcs jobs for mediawiki/core

I have deployed two phpcs jobs for mediawiki/core

From there we will want to tweak our code sniffer standard and/or fix mediawiki core style issues. Then we can make the job voting.

Not that much of a high priority, still have to clear out the Jenkins jobs and adapt related Zuul triggers.

Change 153575 had a related patch set uploaded by Addshore:
make mw-core-phpcs-lenient-HEAD voting!

As part of simplification effort for phpcs, I'm closing this.

The sniffer config should contain the errors and warnings we want to enforce. The rest is irrelevant. We have a fixed coding style. It changes, but it doesn't have multiple states at once. This is over-complication for no good reason.

Change 153575 abandoned by Hashar:
make mw-core-phpcs-lenient-HEAD voting on master!

The continuous integration configuration files are now held in integration/config.git with Zuul layout files being under /zuul/layout.yaml

If there still is an interest in this patch, please port it to the new repository integration/config.git