Rough overview of different kinds of jobs
* jslint
* phplint
* jsduck
* jsduck-publish
* npm
* whitespaces
* phpcs
* rubylint
* ruby1.8lint
* ruby1.9.3lint
* ruby2.0lint
* pplint
* puppetlint
* perllint
* phpunit
* erblint
* mwext/qunit
* mwext/phpunit-testextension
Two major tasks:
1. Consolidate these into generic jobs that can be spawned for any project (instead of substituted for each project, like "foo-bar-jslint", "foo-bar-npm" etc.
2. Consolidate these different build steps into a single build (e.g. phplint/phpcs/phpunit -> composer, jslint/qunit/npm/qunit-karma -> npm).
Thus resulting in a Zuul layout where a project basically only does this:
```lang=yaml
projects:
- name: oojs
test:
- npm-test
gate:
- npm-test
postmerge:
- npm-doc-publish
publish:
- npm-doc-publish
- name: cdb
test:
- composer-test
gate:
- composer-test
postmerge:
- doxygen-doc-publish
publish:
- doxygen-doc-publish
```
With some projects doing both `npm-test` and `composer-test`, or even just combining them in a single optional job like `composer-npm-test`. Would remove need for templates.
Filing this as blocking T47499 as it is crucial to de-duplicate our jobs and simplify our jobs to scale. It also has the added benefit of making this a lot easier to run locally (e.g. running `composer test` would do the same in Vagrant as in Jenkins).
Depending on progress on individual projects' technical debt, we will most likely have to grandfather in a few exceptions. (Such as T89432).