In light of #2254825-8: Add coding standards tests for YAML definition files

Background

  1. There are ~4 test-bot/infrastructure maintainers.
  2. There are 1,000+ core contributors.

Goal

  1. Make Drupal core control the full test suite.
  2. Enable alternative test categories/suites.
  3. Make the "testbot" code accessible and move maintenance into Drupal core.

Proposed solution

  1. $ 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

  1. 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.

Comments

sun’s picture

Status: Active » Needs review
StatusFileSize
new2.95 KB

anavarre queued 1: test.suite_.1.patch for re-testing.

nick_schuch’s picture

I 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.

sun’s picture

Great, 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.

nick_schuch’s picture

Sorry, 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.

nick_schuch’s picture

I've emailed @jthorson and asked if we can have a discussion later in the day.

ricardoamaro’s picture

How is the status on this?

sun’s picture

Status: Needs review » Active

Work 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.

nick_schuch’s picture

StatusFileSize
new178.76 KB
new162.1 KB

Note: 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.

nick_schuch’s picture

StatusFileSize
new178.76 KB
new1.78 KB

Here are the TravisCI files as well. Im going to start running with PHP5.6, 5.5 and 5.4 as well.

nick_schuch’s picture

As 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

mgifford’s picture

Assigned: sun » Unassigned

Just unassigning issues that haven't been developed for a bit in the D8 queue.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Component: other » phpunit

Just moving to the testing component, phpunit.

mile23’s picture

Status: Active » Closed (outdated)

Goals in the issue summary:

  1. Make Drupal core control the full test suite.
  2. Enable alternative test categories/suites.
  3. Make the "testbot" code accessible and move maintenance into Drupal core.

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.