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. (T91996) 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. (This task) 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:

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).

See also:

• T91997: Replace project-specific "{name}-thing" jobs with generic "thing" ones