The Jenkins continuous integration environment at ​http://djangoci.com is setup to build pull requests ​using this plugin.

Commands

Admins can comment "buildbot, test this please." on a a pull request to trigger a build (and whitelisted users can do so on their own PRs). Jenkins polls GitHub every 5 minutes to pickup new changes so there may be a short delay after a comment before the build is triggered. For trusted users, builds are automatically triggered for new pull requests and when a pull request is updated.

The ​main pull request builder runs on Ubuntu 14.04 with PostgreSQL 9.4 and MySQL 5.6. GIS: GDAL 1.10.1, GEOS 3.4.2, PostGIS 2.1

Other pull request builders which can be triggered manually with the corresponding comment phrases:

• ​Ubuntu 12.04 builder runs on PostgreSQL 9.1 and MySQL 5.5. GIS: GDAL 1.7.3, GEOS 3.2.2, PostGIS 1.5.3
  • buildbot, test on precise.
• ​Oracle builder runs on Oracle 11.2.0.1.0. The Oracle tests take about 40 minutes, so we avoid them unless we suspect a change may have broken something on Oracle.
  • buildbot, test on oracle.
• ​Selenium builder also runs the selenium tests.
  • buildbot, test on selenium.

Admins can comment, "buildbot, add to whitelist." to add a user to the trusted list. Whitelisted users will have their pull requests built automatically. In general if you submit a couple of solid PRs, we'll be happy to add you to this list.

The admins list is primarily core developers and is accessible at ​http://djangoci.com/job/django-pull-requests/configure for those with a Jenkins account. The White list is available on the same page after clicking "Advanced". If you are doing a lot of triage work and think it'd be helpful to trigger builds, ask the ​ops team for access.

Other checks

Three builders run on all pull requests:

• ​flake8 - runs the equivalent of flake8 from the root checkout directory and fails if there are any warnings
• ​docs - runs the equivalent of make spelling from the docs directory and fails if there are any spelling or sphinx errors.
• ​isort - runs isort --recursive --check-only . from the root checkout directory and fails if any imports aren't ​sorted properly.

Troubleshooting

If:

1. you force push to a branch after the initial build starts or
2. a commit is pushed to master after the initial build starts

You will see an error like git checkout <hash> where hash was not the commit. Currently the only solution is to retrigger the build. There is a ​ticket for the issue in GitHub Pull Request Builder.