Continuous integration/Entry points

The BoilerPlate sample code extension implements these entry points. You can start from its code.

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

Example: You will need .jshintignore, .jshintrc, and .jscsrc files in your project; see the files from one of the "Good examples" project below or from extensions/BoilerPlate.

If your project needs more complex building processes, the convention is to use Grunt as task runner. For example:

Good example: Further reading:
 * 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 for mediawiki i18n)
 * package.json format on docs.npmjs.org
 * package "scripts" lifecycle on docs.npmjs.org

In Debian/Ubuntu, if npm test fails with /usr/bin/env: node: No such file or directory then you may need to install the package nodejs-legacy.

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

Testing PHP
We are using composer test as an entry point. If your project has PHP files it should list the test framework packages it needs in composer.json 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 composer.json and composer test.

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 composer test for e.g. a JUnit report.

PHP Documentation
See: Doxygen.

Create a  in the project root.

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

Ruby
Use bundler to define your commands.

T104024 discusses an entry point.