Continuous integration/Entry points

Testing JavaScript
We are using  as an entry point. If your project has JavaScript files, it should at least have a  file and define a   script.

You will need the .jshintignore, .jshintrc, and .jscsrc configuration files in your project (see Manual:Coding conventions/JavaScript). Look at one of the projects listed in the example section below for an example of these files.

Grunt task runner
If your project has complex build processes or is an extension or skin that will benefit from i18n checking and JSON file linting, the convention is to use Grunt as a task runner. Your project still has a package.json file, which has a dependency on  and sets. In turn, a Gruntfile.js file implements , and this can run a wide variety of tools and tests:
 * jscs
 * jshint
 * banana-checker which checks messages in MediaWiki i18n files.
 * jsonlint which checks JSON files including composer.json and extension.json for conformance.

You can specify configuration settings for these tools in Gruntfile.js. However, it should contain little to no configuration for tools that can run outside  so that they operate the same when run standalone or from a text editor plugin. Always use native configuration files where possible, including .jshintignore</tt>, .jshintrc</tt>, and .jscsrc</tt> mentioned above.

JavaScript documentation
Use  as the entry point. The convention is to use JSDuck. The  and   script hooks in   can be used to run any additional scripts (e.g. build files for inclusion beforehand, or copy additional files for publication afterward).

Examples
Basic setup:

Advanced setup using Grunt:

Example projects:
 * Extension:BoilerPlate has a </tt> that runs jshint, jscs, and banana-checker (for MediaWiki's i18n</tt> JSON files).
 * jquery-client: package.json (jshint, jscs, karma; no Grunt needed)
 * CSSJanus: package.json / Gruntfile.js (jshint, jscs, custom test)
 * TemplateData: package.json / Gruntfile.js (jshint, jscs, banana-checker)

Further reading:
 * package.json format on docs.npmjs.org
 * package "scripts" lifecycle on docs.npmjs.org

Testing PHP
We are using  as an entry point. If your project has PHP files it should list the test framework packages it needs in  under   and list the commands to be run in the   property:

See for a good example.

Note that MediaWiki extensions are not standalone projects and cannot run their own PHPUnit test suite from composer, those repositories have a separate  job. PHPCS and PHP lint are still run via  and.

When running the suite under Jenkins, we might want to capture the test results to publish them on the build page. Since your test entry point has multiple commands, the extra arguments are set by Jenkins and should be included in each script command. By convention, the environment variable holding these arguments is all upper case, with the command line name suffixed with :

The Jenkins job can then set these environment variables to inject additional arguments when invoking  for e.g. a JUnit report.

PHP Documentation
See: Doxygen.

Use the doxygen program to generate a  file in the project root.

Testing Python
See Continuous integration/Tutorials/Test your python.

Ruby
Use rake to define your commands, they will be executed via bundler.

Example Rakefile</tt>: ```

Will teach to rake the following tasks: $ rake -T rake doc                  # Generate all documentations rake rubocop              # Run RuboCop rake rubocop:auto_correct # Auto-correct RuboCop offenses rake spec                 # Run RSpec code examples rake test                 # Run all build/tests commands (CI entry point) rake yard                 # Generate YARD Documentation $

The Jenkins job rake-jessie</tt> invokes bundle exec rake test</tt>.

Reference: T104024