Continuous integration/Entry points

Generating documentation
We are using  as an entry point. So if your project generates documentation, it should have a Makefile with a  target.

Testing JavaScript
We are using  as an entry point. So if your project has JavaScript files, it should have a package.json file with at least a script definition.

Our convention is to use Grunt as a task runner, so package.json might contain:

In turn,  can run automated JSHint, JSCS, and QUnit or Karma tests; Grunt has plugins for these tests such as grunt-contrib-jshint and as you see in the sample above, you mention these plugins in package.json along with grunt. So your project will have a Gruntfile.js that registers the top-level  task and associates it with these specific tests.

See the package.json and Gruntfile.js of CSSJanus for a good example.

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

See for a good example.

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. Checkstyle or JUnit report.

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

Ruby
Use bundler to define your commands.