In light of #2254825-8: Add coding standards tests for YAML definition files
Background
- There are ~4 test-bot/infrastructure maintainers.
- There are 1,000+ core contributors.
Goal
- Make Drupal core control the full test suite.
- Enable alternative test categories/suites.
- Make the "testbot" code accessible and move maintenance into Drupal core.
Proposed solution
-
$ core/scripts/test.sh Usage: core/scripts/test.sh <suite> [options] <path> Execute from the root directory of your Drupal site. Test suites: -a | --all All available test suites. --phplint PHP lint. --jslint JS lint. --phpunit PHPUnit. --simpletest Simpletest. Arguments: <path> The path for which to run tests. Argument examples: core Runs tests for all of core. core/modules/node Runs tests for Node module. modules/devel Runs tests for Devel module. (assuming Devel module is located in /modules/devel) Options: -h | --help This help. -v | --verbose Enable verbose output. -o | --out <path> Path to use for test results/artifacts. Defaults to './test'. --color Enable colorful output. Arguments and options can be specified in any order, as long as values for options that require a value are passed after the corresponding option.
Notes
-
This is explicitly limited to GNU Bash shells.
Windows users (like me!) have to install Cygwin/Mingw32 to execute this script. Windows will not be supported natively.
MacOSX and FreeBSD users have to install the GNU getopt port via
sudo port install getopt. (details) Only Linux will be supported natively.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | mod_php-travis.yml | 1.78 KB | nick_schuch |
| #10 | apache-mod_php.txt | 178.76 KB | nick_schuch |
| #9 | apache-php_fpm.txt | 162.1 KB | nick_schuch |
| #9 | apache-mod_php.txt | 178.76 KB | nick_schuch |
| #1 | test.suite_.1.patch | 2.95 KB | sun |
Comments
Comment #1
sunComment #3
nick_schuch commentedI completely agree with moving the responsibility of the testing "steps" into the project.
There has been alot of work done in the following repository: https://github.com/nickschuch/docker-drupal (I apologise for the generic project name).
I plan to bring this up in the DrupalCI meeting in the morning so we can hopefully formalise it.
Comment #4
sunGreat, I plan to attend, too. — For anyone else interested: Join IRC #drupal-testing today, Sunday, 2014-08-24 20:00 UTC.
The need for a custom "wrapper" shell script as in #1 will probably be obsolete with that approach.
Comment #5
nick_schuch commentedSorry, I wasn't able to make it, I couldn't find a spot that was out of the way from the house that Im staying at for the weekend.
Comment #6
nick_schuch commentedI've emailed @jthorson and asked if we can have a discussion later in the day.
Comment #7
ricardoamaro commentedHow is the status on this?
Comment #8
sunWork is happening in https://github.com/nickschuch/docker-drupal
Specifically https://github.com/nickschuch/docker-drupal/issues/17 + https://github.com/nickschuch/drupal/pull/3
The dispatcher script idea in the issue summary / patch is obsolete.
Comment #9
nick_schuch commentedNote: I have also posted this same message to the github issue.
Here is where we stand (see attachments for log output):
Apache + PHP-FPM (fastcgi) - 1 hr 44 min
Fails on 4 tests due to either shutdown functions or race condititions, however, I feel this is a solid proof of concept for running php-fpm instead.
Drupal\path\Tests\PathAliasTest - Shutdown functions.
Drupal\config\Tests\ConfigImportAllTest - Race condition with importing configuration in CMI.
With FPM setup in this fashion we know exactly what version of php we are running on both the cli and in apache. It is also scalable when adding more PHP environments eg. 5.5 and 5.6..
It also turns out this method is 25min faster than Apache + mod_php!
Apache + mod_php - 2 hr 10 min
The test suite is passing!
The downside is that it is not easily scalable if we want to run more PHP environments. One workaround on this for now would be to check the PHP environment version and install the required Ubuntu PPA repository.
Recommendation
1) Commit the Apache + mod_php on the proviso.
2) Work towards supporting FPM so we can take advantage of PHPENV versioning.
Comment #10
nick_schuch commentedHere are the TravisCI files as well. Im going to start running with PHP5.6, 5.5 and 5.4 as well.
Comment #11
nick_schuch commentedAs a part of these efforts I have now run the test suite against 5.4, 5.5 and 5.6. The results can be found here:
https://www.drupal.org/node/2334471#comment-9128515
Comment #12
mgiffordJust unassigning issues that haven't been developed for a bit in the D8 queue.
Comment #25
quietone commentedJust moving to the testing component, phpunit.
Comment #26
mile23Goals in the issue summary:
1) Since 2014 we obviously went in a different direction. We moved testing off of a Drupal-based test runner and onto first DrupalCI and now Gitlab-based tools.
2) Users can create their own test suites, as is the case with DTT. This is the result of refactoring the testing system into PHP traits, among other things.
3) The DrupalCI test bot is open, and the Gitlab work is also open.
I declare this issue to be outdated. Follow up with a new one for any lingering concerns.