This project is not covered by Drupal’s security advisory policy.
THIS PROJECT IS DEPRECATED, This is not the issue queue for D.O. Testbots
Please file Testbot issues with http://drupal.org/project/drupalci_testbot
This project is a place for issues to be filed or questions to be asked about the Drupal.org testbots and all the projects related to them. Since there are so many d.o projects involved it seems that most people just need a one-stop shop for issues. They can be moved out from here.
Frequently Asked Questions
- How do I enable automated testing for my project? Look for the 'Enable Automated Testing' checkbox on your project's 'Automated Testing' tab. (docs page) (issue)
- Why is my patch marked "postponed"? Most of the time this is because the branch you're testing against hasn't passed tests. Follow the "branch" link on the qa.drupal.org page explaining that your patch is postponed and you'll see the status of branch testing. Usually some work is required on the branch (and tests won't succeed without new commits).
- Why does my test fail on the testbot but works OK locally? There are probably three key differences between your local test environment and the testbot
- The testbot is running PHP 5.4.39 (from dotdeb)
- The testbot has clean URLs turned off by default (as does Drupal)
- The testbot webroot is in a subdirectory (like http://drupaltestbot.osuosl.test/checkout/?q=admin)
- The testbot runs tests using run-tests.sh. Try using that technique and see if your tests succeeeds
- The testbot has to be able to run through the install process, then log in and enable simpletest and visit the testing page, all using the web UI. Have you tried that?
- The testbot starts with all modules disabled and the tests themselves enable them. Disable your relevant modules so that they're not active locally before running local tests to get a reasonable result.
- The testbot uses the issue version to determine which codebase to test against. Ensure the issue the patch has been uploaded to is set to a -dev release, as opposed to a specific release checkout.
- If you get "failed to apply", check that the issue is set to the *branch*, not a specific tag. For example, an issue with a patch should be set to "7.x-1.x-dev", not "7.x-1.3". Try to apply the patch to a local repository just to make sure. If it fails on the testbot, it will fail locally too, if you're using "git apply".
- If installation is failing, please try installing Drupal with your patch applied. Your patch may cause a failure in the installation.
- I changed dependencies in my .info file, but the wrong dependencies are still being loaded on test Dependencies only get built when the new dev release is rolled, every 12 hours. So if you change dependencies, it won't be reflected until the new dev tarball is rolled.
- I'm pretty sure a testbot is misbehaving (Can't drop database... Can't clear checkout directory... Hasn't done a test in a few hours...) What should I do? If you have an account on qa.drupal.org, visit the testbot's test page and reconfirm it (links to all testbot pages). That will cause the testbot to fail (if you're right) and take it out of the rotation until we can fix it. If you don't have an account, find somebody who does or file an issue right here. If you want an account and we can spell your name you'll probably get one. Just open an issue and ask.
- My patch failed due to a failure in an unrelated test, but when I retested it, it passed. What should I do? If you think the first failure might have been testbot related, then open an issue here. If it turns out to be a problem with the test itself intermittently failing, we'll tag it with Random test failure and bounce it to the core issue queue.
Jenkins Procedures for Administrators
- project_dependency_rebuild_project takes a space-delimited set of project shortnames and rebuilds dependencies for all of them. Looking at the console output is useful when looking for problems.
- project_dependency_show_dependencies will get the current dependency calculations (you need to look at the console output)
- project_dependency_remove_sourcecode removes all of the checkouts for all projects. It takes a few minutes or seconds, but should be completely safe, and sometimes resolves incomprehensible problems.
Testbot Admin Procedures
- [MySQL] Setup environment: failed to drop checkout database. This is invariably due to /tmpfs being full. (screencast) (more difficult scenario)
- ssh into the testbot in question
- rm -rf /tmpfs/mysql/drupaltestbotmysql/simpletest*
- service mysql restart
- drop database drupaltestbotmysql
- create database drupaltestbotmysql (not these last two steps may not be necessary
- Failed to clear checkout directory: This is almost always a result of somebody mucking on the testbot.
- ssh into the testbot
- rm -rf /var/lib/drupaltestbot/checkout/*
- That usually does it, but there may be dot files remaining in that directory.
- Creating a testbot: See Creating a Drupal testbot (screencast)
Related projects and documentation
- Automated testing system documentation
- drupaltestbot-puppet (testbot puppet configuration)
- drupaltestbot The Debian packages used to build the testbots
- Project Issue File Review
- Project Issue File Test
- qa.drupal.org (The dispatcher for tests)
- Automated Testing Infrastructure
Related projects (next generation)
- Maintenance status: Actively maintained
- Development status: Under active development
- Last modified: 23 June 2016
- This project is not covered by the security advisory policy.
Use at your own risk! It may have publicly disclosed vulnerabilities.