Continuous integration/Entry points

We have standardized on the following tools for testing our code: Documentation on how to configure and set up these tools can be found below.

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  configuration file 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  file, which has a dependency on   and sets. In turn, a  file implements , and this can run a wide variety of tools and tests:
 * , which checks both JS and JSON files.
 * , which checks both CSS and LESS files.
 * , which checks messages in MediaWiki i18n files.

You can specify configuration settings for these tools in. 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  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).

Example projects:

 * Extension:BoilerPlate has a  that runs jshint, jscs, and banana-checker (for MediaWiki's   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.

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.

Rake
Use Rake to define your commands, they will be executed via Bundler.

Example :

The above code will create following Rake targets.

$ bundle exec rake -T

rake rubocop              # Run RuboCop rake rubocop:auto_correct # Auto-correct RuboCop offenses rake selenium             # Run Cucumber features rake test                 # Run all build/tests commands (CI entry point)

The Jenkins job  invokes   target by running.

Reference: T104024

ruby debug tip
You can use the gem  to break on error and get shown a console in the context of the failure. To your Gemfile add  then to break:

You will then be in a console before the breakage that let you inspect the environment. See https://github.com/pry/pry for details.

ci.yml
We have a set of Jenkins jobs that run daily and execute Ruby + Selenium tests. The jobs are named.

Each repositories has only a single job defined in Jenkins. It is a multi configuration job that spawns one or more child job based on a configuration in each repositories:. The main job will then spawn child jobs based on its content.

Example of a simple is in.

As you can see, there are three variables,,   and.

and  can be any valid Sauce Labs browser/OS/version combination.

can have values,   and  , or any other environment configured in.

For example:

Example of a complicated is in. For more information see Jenkins Yaml Axis Plugin.

Reference: T128190