Problem/Motivation

Over in #2494987: [meta-6] Reduce cold cache memory requirements we're tracking fixing instances where we exceed the 64MB memory limit.
I asked if we'd like simpletest to try and help us find such pages.

Proposed resolution

Add a header for peak memory usage when running the child site.
Have the parent runner read it and fail tests when it exceeds 64Mb.
Let tests opt-out.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category
Unfrozen changes Unfrozen because it only changes test code
Prioritized changes The main goal of this issue is scalability (preventing memory usage regressions).

Remaining tasks

Most of it

User interface changes

None

API changes

None

CommentFileSizeAuthor
#171 2495411_171.patch14.36 KBMile23
#167 2495411-167.patch14.33 KBlokapujya
#164 2495411-163.patch15.88 KBlokapujya
#161 2495411-3-161.patch15.98 KBalexpott
#161 159-161-interdiff.txt837 bytesalexpott
#159 2495411-3-159.patch15.45 KBalexpott
#159 157-159-interdiff.txt5.64 KBalexpott
#157 2495411-3-157.patch18.36 KBalexpott
#157 154-157-interdiff.txt2.44 KBalexpott
#154 2495411-154.patch12.13 KBcatch
#150 2495411-149-96M.patch11.6 KBcatch
#149 2495411-149-64M.patch11.6 KBcatch
#141 interdiff.txt870 byteseffulgentsia
#141 2495411-2.137-32M.patch11.6 KBeffulgentsia
#137 2495411-2.137.patch11.6 KBcatch
#135 2495411-2.135.patch11.6 KBalexpott
#135 133-135-interdiff.txt899 bytesalexpott
#133 2495411-2.133.patch11.6 KBalexpott
#133 115-133-interdiff.txt2.08 KBalexpott
#131 simpletest-2495411-110M.patch10.08 KBcatch
#129 simpletest-2495411-100M.patch10.08 KBcatch
#127 simpletest-2495411-63M.patch10.08 KBcatch
#122 simpletest-2495411-56M.patch10.08 KBcatch
#122 simpletest-2495411-48M.patch10.08 KBcatch
#122 simpletest-2495411-40M.patch10.08 KBcatch
#122 simpletest-2495411-32M.patch10.08 KBcatch
#115 simpletest-2495411-115.patch10.08 KBalmaudoh
#75 intediff-docs.txt5.58 KBxjm
#75 simpletest-2495411-75.patch10.1 KBxjm
#71 2495411-test.71.patch10.06 KBalexpott
#71 69-71-interdiff.txt1.11 KBalexpott
#55 2495411-test.55.patch8.54 KBalexpott
#55 43-55-interdiff.txt5.25 KBalexpott
#43 2495411-39.patch7.44 KBcatch
#41 2495411-39.patch7.44 KBcatch
#37 2495411-37.patch5.48 KBcatch
#35 2495411.patch7.44 KBcatch
#35 interdiff.txt5.02 KBcatch
#33 2495411.33.patch3.7 KBcatch
#31 2495411.31.patch3.7 KBalexpott
#31 23-31-interdiff.txt762 bytesalexpott
#23 memory-usage-trigger-2495411.12.patch3.69 KBcatch
#12 memory-usage-trigger-2495411.12.patch3.69 KBlarowlan
#12 interdiff.txt1.35 KBlarowlan
#10 memory-usage-trigger-2495411.4.patch3.64 KBlarowlan
#10 interdiff.txt759 byteslarowlan
#8 memory-usage-trigger-2495411.p3.patch3.64 KBlarowlan
#8 interdiff.txt2.53 KBlarowlan
#3 memory-usage-trigger-2495411.2.patch3.63 KBlarowlan
#3 interdiff.txt842 byteslarowlan
#2 memory-usage-trigger-2495411.p1.patch3.6 KBlarowlan
#61 55-60-interdiff.txt5.11 KBalexpott
#61 2495411-test.60.patch9 KBalexpott
#62 60-62-interdiff.txt4.68 KBalexpott
#62 2495411-test.62.patch9.78 KBalexpott
#64 62-64-interdiff.txt1.68 KBalexpott
#64 2495411-test.64.patch10.01 KBalexpott
#69 64-69-interdiff.txt1.19 KBalexpott
#69 2495411-test.69.patch10.03 KBalexpott
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

larowlan’s picture

adapting some existing code from D7

larowlan’s picture

Assigned: larowlan » Unassigned
Status: Active » Needs review
FileSize
3.6 KB

Here goes

larowlan’s picture

And with the opt-out

The last submitted patch, 2: memory-usage-trigger-2495411.p1.patch, failed testing.

tim.plunkett’s picture

  1. +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
    @@ -46,7 +48,7 @@ public function on500(GetResponseForExceptionEvent $event) {
    -    if (DRUPAL_TEST_IN_CHILD_SITE && !headers_sent() && (!defined('SIMPLETEST_COLLECT_ERRORS') || SIMPLETEST_COLLECT_ERRORS)) {
    +    if ($this->addHeaders()) {
    

    Fine to do, but that method name sounds like it is adding the headers itself.

  2. +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
    @@ -64,4 +66,40 @@ public function on500(GetResponseForExceptionEvent $event) {
    +  public function onException(GetResponseEvent $event) {
    ...
    +    $events[KernelEvents::RESPONSE][] = ['onResponse', 100];
    

    Mismatched name?

  3. +++ b/core/modules/simpletest/src/WebTestBase.php
    @@ -60,6 +60,20 @@
    +  protected $memoryUsageTrigger = 64;
    

    Any reason not to use DRUPAL_MINIMUM_PHP_MEMORY_LIMIT? (other than the M)
    Just one less place to adjust the number.

  4. +++ b/core/modules/simpletest/src/WebTestBase.php
    @@ -1297,6 +1311,15 @@ protected function curlHeaderCallback($curlHandler, $header) {
    +        $this->fail(format_string('Child site memory usage (@siteMB) exceeded acceptable maximum (@maxMB) on url @url', [
    

    wtf why is format_string not @deprecated? either way, SafeMarkup::format please

YesCT’s picture

Issue tags: +Performance

Status: Needs review » Needs work

The last submitted patch, 3: memory-usage-trigger-2495411.2.patch, failed testing.

larowlan’s picture

Status: Needs work » Needs review
FileSize
2.53 KB
3.64 KB

Fixes #5 1,2,4 as well as php syntax (doh)
3 - cause some tests might want it to be smaller.

Status: Needs review » Needs work

The last submitted patch, 8: memory-usage-trigger-2495411.p3.patch, failed testing.

larowlan’s picture

Status: Needs work » Needs review
FileSize
759 bytes
3.64 KB

not my day today

Status: Needs review » Needs work

The last submitted patch, 10: memory-usage-trigger-2495411.4.patch, failed testing.

larowlan’s picture

Status: Needs work » Needs review
FileSize
1.35 KB
3.69 KB

Status: Needs review » Needs work

The last submitted patch, 12: memory-usage-trigger-2495411.12.patch, failed testing.

larowlan’s picture

Fails:

Drupal\views\Tests\Plugin\DisplayTest
Drupal\views\Tests\ViewExecutableTest
Drupal\user\Tests\Views\HandlerFieldRoleTest
Drupal\simpletest\Tests\SimpleTestBrowserTest
Drupal\simpletest\Tests\SimpleTestTest
Drupal\simpletest\Tests\OtherInstallationProfileTestsTest
Drupal\simpletest\Tests\BrokenSetUpTest
Drupal\simpletest\Tests\MissingCheckedRequirementsTest
Drupal\simpletest\Tests\InstallationProfileModuleTestsTest

Running them locally should get you the urls/conditions.

Berdir’s picture

Looks like the script was killed at the end, that happens if there's a timeout. The test was running for 1h.

Maybe it was a bot problem, re-testing.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 12: memory-usage-trigger-2495411.12.patch, failed testing.

Fabianx’s picture

larowlan++ - Nice work, I just commented on that blog post on planet for memory_profiler that we should be doing that in our tests. You already did :p. Nice!

Fabianx’s picture

Berdir’s picture

+++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
@@ -64,4 +66,41 @@ public function on500(GetResponseForExceptionEvent $event) {
+  protected function canAddHeaders() {
+    return (DRUPAL_TEST_IN_CHILD_SITE && !headers_sent() && (!defined('SIMPLETEST_COLLECT_ERRORS') || SIMPLETEST_COLLECT_ERRORS));

is the headers_sent() thing really still relevant? ;)

So, the only tests that failed are simpletest tests. I'm wondering if that's really correct but it's quite possible, because I guess we don't have any standard profile tests that submit the module page. Just for testing, can you add that to StandardProfileTest or so? according to the numbers that we saw, that should still happen there right now?

I think it's safe to ignore this for the simpletest test, pretty sure we don't have the requirement to run all tests with 64MB ?

Fabianx’s picture

I wonder if it would pass with 128 MB ...

plach’s picture

+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -60,6 +60,20 @@
+  protected $ignoreMemoryUsage = FALSE;
...
+  protected $memoryUsageTrigger = 64;

Couldn't we merge these two? E.g. $this->memoryUsageTrigger = FALSE; could disable the memory usage check.

catch’s picture

Status: Needs work » Needs review
FileSize
3.69 KB

Trying 128, might as well bisect this.

Berdir’s picture

I'm confused, the failure says exactly how much memory it used, no need to try and figure out out? :)

Child site memory usage (79.07 MB) exceeded acceptable maximum (64MB) on url http://ec2-52-8-80-151.us-west-1.compute.amazonaws.com/checkout/user/2

catch’s picture

Yes, yes it does.

The last submitted patch, 12: memory-usage-trigger-2495411.12.patch, failed testing.

catch’s picture

Status: Needs review » Needs work

OK https://qa.drupal.org/pifr/test/1056818 is now just simpletest's own tests of itself.

We're fine having those opt-out of the 64mb check, so I think we should do that then go ahead and commit this.

Fabianx’s picture

Priority: Normal » Major

The parent being critical, this is major at this stage.

dawehner’s picture

+++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
@@ -64,4 +66,41 @@ public function on500(GetResponseForExceptionEvent $event) {
+      $memory_usage = memory_get_usage();
...
+        'X-Drupal-Memory-Peak' => round($memory_usage / 1024 / 1024, 2),

Don't we want to call out to memory_get_peak_usage() in case we want to get the peak memory usage ^^ :)

alexpott’s picture

Status: Needs work » Needs review
FileSize
762 bytes
3.7 KB

Addressing #30 and setting back to 64mb

plach’s picture

+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -60,6 +60,20 @@
+   * Set to TRUE to ignore memory usage on the child site.
+   *
+   * @var bool
+   */
+  protected $ignoreMemoryUsage = FALSE;
+
+  /**
+   * Set to the maximum number of MB of memory usage to allow on the child site.
+   *
+   * @var int
+   */
+  protected $memoryUsageTrigger = 128;
+
+  /**
    * The handle of the current cURL connection.

Two things:
- it's still 128M
- I think merging these two properties would be better for DX: IMO it would be easier to use the setting if to disable it we could just use an invalid value, like 0 or -1.

catch’s picture

FileSize
3.7 KB

Uploading a patch with 64M just to get a test run with it.

I do think merging the properties is good - and even memory-hogging tests we could set something like 256M in most cases since going over that is useful information too.

Status: Needs review » Needs work

The last submitted patch, 33: 2495411.33.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
5.02 KB
7.44 KB

Removed the separate property, and updated simpletest tests.

I get a couple of failures locally that look unrelated, see what the bot says.

Since the bots run with an opcode cache, we should consider bisecting this with lower memory limits a bit and set to the lowest that passes for the default to give a bit of head room.

plach’s picture

+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -1399,6 +1406,15 @@ protected function curlHeaderCallback($curlHandler, $header) {
+    if (preg_match('/^X-Drupal-Memory-Peak: (.*)$/', $header, $matches)) {
+      if ((float) $matches[1] >= $this->memoryUsageTrigger) {
+        $this->fail(SafeMarkup::format('Child site memory usage (@siteMB) exceeded acceptable maximum (@maxMB) on url @url', [
+          '@url' => $this->getUrl(),
+          '@site' => $matches[1],
+          '@max' => $this->memoryUsageTrigger,
+        ]));
+      }
+    }

How is this skipping the check when we have an invalid value? Shouldn't we do something like this?

if ($this->memoryUsageTrigger && preg_match('/^X-Drupal-Memory-Peak: (.*)$/', $header, $matches)) {
  // Do stuff
}

Minor, we could alse merge the nested if.

catch’s picture

FileSize
5.48 KB

Addressing both points from #36.

The last submitted patch, 35: 2495411.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 37: 2495411-37.patch, failed testing.

plach’s picture

From https://qa.drupal.org/pifr/test/1070008:

Drupal\system\Tests\Module\InstallUninstallTest:
Child site memory usage (64 MB) exceeded acceptable maximum (64MB) on url http://ec2-52-26-179-253.us-west-2.compute.amazonaws.com/checkout/admin/...

Nice :D

catch’s picture

Status: Needs work » Needs review
FileSize
7.44 KB

#37 was the wrong patch.

That new failure is fun since it was passing a few days ago.

Status: Needs review » Needs work

The last submitted patch, 41: 2495411-39.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
7.44 KB

Oh dear.

Status: Needs review » Needs work

The last submitted patch, 43: 2495411-39.patch, failed testing.

catch’s picture

@alexpott pointed out that InstallUninstall test probably started failing because we switched to memory_get_peak_usage(), which is of course a good change.

I just demoted the critical relating to module installation because a single module install was well under 64M on my system, but I think that test does multiple modules, or it could be PHP 5.4 vs. PHP 5.5.

#2451395: drupal_get_schema()/drupal_get_complete_schema() no longer work as expected; remove them may be enough to get us under. Will post combined patch once that issue has come back green.

catch’s picture

and/or #2495073: Views feed display plugin has to get all views data on init which was already RTBC but got bot fluked.

catch’s picture

Status: Needs work » Needs review

catch queued 43: 2495411-39.patch for re-testing.

plach’s picture

Status: Needs review » Reviewed & tested by the community
+++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
@@ -64,4 +66,41 @@ public function on500(GetResponseForExceptionEvent $event) {
+      $event->setResponse($response);

Very minor: not sure this is needed.

xjm’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests, +Needs followup

This is great.

Should we add test coverage for the memory check? E.g. test it with a really low limit.

Also, should we file followups for the ones where we are using 128 MB, to remove them when we get the memory usage down (maybe issues exist already in some cases), and then reference those in @todo where we're setting 128 MB?

I have no idea about #49.

alexpott’s picture

Status: Needs work » Reviewed & tested by the community

The 128mb is due to reading all of the test files. There is not really anyway around there other than having less tests.

Adding a low memory test say of a cache page response is out of scope for this issue which is about enforcing our limit.

@plach is correct but there is no harm in the line.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 43: 2495411-39.patch, failed testing.

xjm’s picture

@alexpott I meant test coverage for the functionality added by the patch, which would seem to be in scope for the patch. We're adding a property to tests that is not documented or tested. That should be in scope for this issue, no?

xjm’s picture

Assigned: Unassigned » alexpott

@alexpott and I discussed this in IRC. He is looking into the possibility of adding tests, and also said he found a different problem with the patch (I don't know what).

alexpott’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests, -Needs followup
FileSize
8.54 KB
5.25 KB

I've added assertions to SimpletestTest to ensure we get failures if the limit is exceed. I've also bump the testing that load the Simpletest UI to 140mb because without that I could not get them to run locally.

I'm removing the "need followup" because we can't reduce the memory required for Simpletest UI unless we don't read all the test files to find their description and group.

xjm’s picture

So to clarify for the interdiff in #55, I checked with @alexpott in IRC and the 140 MB is not a change for him locally since the previous patch (i.e. not some huge memory regression in HEAD); just a difference between his local and testbot. And obviously we need to let the tests be run locally.

xjm’s picture

+++ b/core/modules/simpletest/src/Tests/BrokenSetUpTest.php
@@ -30,6 +30,11 @@ class BrokenSetUpTest extends WebTestBase {
   /**
+   * The memory limit for this test, Testing module requires 128M.
+   */
+  protected $memoryUsageTrigger = 140;

Oh, but the comments for these don't match the number now. Hm. Though it is true AFAIK that the simpletest memory requirement is 128 MB (and declared as such in a constant).

alexpott’s picture

@xjm yeah not sure want to do here. I think we've got a couple of options...

Option 1: the simplest thing is to raise the limit of the testing module - even on the bots when it was 128M it was very close so adding more tests could eventually start breaking this.

Option 2: Perhaps the way to go is to set the limit for these tests to -1 so the limit is not applied and open a followup which profiles on different PHP versions what the Simpletest UI actually takes to display the list. Since testing against drupal's stated memory limit is way more important.

Also another thing I thought - shouldn't we set the default WebTestBase::$memoryUsageTrigger to DRUPAL_MINIMUM_PHP_MEMORY_LIMIT so that all of this is controlled from one place.

/**
 * Minimum recommended value of PHP memory_limit.
 *
 * 64M was chosen as a minimum requirement in order to allow for additional
 * contributed modules to be installed prior to hitting the limit. However,
 * 40M is the target for the Standard installation profile.
 */
const DRUPAL_MINIMUM_PHP_MEMORY_LIMIT = '64M';

Doing that will require deprecating DRUPAL_MINIMUM_PHP_MEMORY_LIMIT for Drupal 9.0 and adding \Drupal::MINIMUM_PHP_MEMORY_LIMIT which I think is fine.

tim.plunkett’s picture

+1 for Option 2, using -1
+1 for reusing the constant, although one has an M and the other doesn't. (I mentioned this in #5.3 above)

alexpott’s picture

I've concluded that coupling DRUPAL_MINIMUM_PHP_MEMORY_LIMIT to the default test memory limit is probably a bad idea because we might want to reduce the simpletest default check but leave DRUPAL_MINIMUM_PHP_MEMORY_LIMIT at 64M.

Looking the memory usage of SimpletestTestForm I need 143Mb not in the when not in the test environment so the current value of SIMPLETEST_MINIMUM_PHP_MEMORY_LIMIT. It appears that over half the amount is used by form rendering (and mostly not SafeMarkup). Rebuilding the list of testing from a cold cache only costs us about 25Mb. This information makes me lean towards option 2 and either, opening a followup issue to address memory usage of SimpletestTestForm, or, adding more information to the permissions memory usage page because this looks like a similar problem - rendering hundreds of checkboxes is expensive.

alexpott’s picture

Implemented option 2 and improved documentation of the WebTestBase property. Opened #2505877: SimpletestTestForm is very memory expensive to track the issue with SimpletestTestForm

alexpott’s picture

Fixed a bug in the patch with the reported URL - $this->getUrl() cannot work in a curl header callback because $this->url has not been set yet :) Added test assertions to ensure we don't re-introduce the bug.

Also changed WebTestBase::$memoryUsageTrigger to accept strings with the format as PHP memory limit because this make conceptual sense to me. Also the header now reports the precise number of bytes which might be more useful in the long if we somehow extract this info from SImpletest and plot it over time.

Status: Needs review » Needs work

The last submitted patch, 62: 2495411-test.62.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
1.68 KB
10.01 KB

Generating the absolute url's in a slightly different way for the test.

dawehner’s picture

+++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
@@ -64,4 +66,38 @@ public function on500(GetResponseForExceptionEvent $event) {
+    return (DRUPAL_TEST_IN_CHILD_SITE && !headers_sent() && (!defined('SIMPLETEST_COLLECT_ERRORS') || SIMPLETEST_COLLECT_ERRORS));

Why do you call out to headers_sent() and then add it to the response object? Isn't that kind of a total different thing?

alexpott’s picture

@dawehner that method is used by the exception listener to - and an exception might occur after the headers sent.

catch’s picture

I've concluded that coupling DRUPAL_MINIMUM_PHP_MEMORY_LIMIT to the default test memory limit is probably a bad idea because we might want to reduce the simpletest default check but leave DRUPAL_MINIMUM_PHP_MEMORY_LIMIT at 64M.

100% agreed with this. Ideally we'd want to keep reducing the simpletest limit as far as we can as core makes improvements (it can always be raised if we regress intentionally for some reason). But we'll likely need 64M as the core memory limit for a while due to people running without opcode caches.

almaudoh’s picture

+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -62,6 +63,20 @@
+   * The minimum about of memory Drupal expects is defined by
+   * DRUPAL_MINIMUM_PHP_MEMORY_LIMIT. This value should either by equal or less
+   * to conform to this requirement. If a module requires more memory than the
+   * module should add a check to its hook_requirements and use the higher value
+   * in it's tests. The check can be disabled for a specific tests by setting it
+   * to FALSE.

Doc block nitpick...

alexpott’s picture

FileSize
10.03 KB
1.19 KB

Interesting english @alexpott :)

Nice spot @almaudoh.

plach’s picture

+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -1399,6 +1414,13 @@ protected function curlHeaderCallback($curlHandler, $header) {
+      $this->fail(SafeMarkup::format('Child site memory usage (@site) exceeded acceptable maximum (@max) on url @url', [
+        '@url' => curl_getinfo($curlHandler, CURLINFO_EFFECTIVE_URL),
+        '@site' => format_size($matches[1]),
+        '@max' => $this->memoryUsageTrigger,

Minor: shouldn't @site be something more meaningful, like @usage or @site_usage?

Aside from that looks good again to me :)

alexpott’s picture

FileSize
1.11 KB
10.06 KB

@plach how about this?

plach’s picture

Status: Needs review » Reviewed & tested by the community

Way better, thanks :)

Berdir’s picture

Response to #60: Last time I checked those page it wasn't so much the checkboxes but just rendering large tables with render arrays.. that results in a ton of render calls and one of the most expensive things there was merging cacheability metadata.. might be worth to check that page in #2471232: Optimize Cache::merge*(), by only accepting 2 instead of N arguments and the related issues about optimizing that.

xjm’s picture

Looks great now. Only super tiny nitpicks, none of which need to block commit:

  1. +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
    @@ -64,4 +66,38 @@ public function on500(GetResponseForExceptionEvent $event) {
    +   * Returns if headers should be added.
    

    Super fussy grammar nitpick: I think this should be something like "Indicates whether headers should be added.: "If" implies that it doesn't return at all if headers should not be added. ;)

  2. +++ b/core/modules/simpletest/src/Tests/SimpleTestTest.php
    @@ -27,6 +29,11 @@ class SimpleTestTest extends WebTestBase {
    +   * The memory limit for this test, the Simpletest UI is very expensive.
    +   */
    +  protected $memoryUsageTrigger = FALSE;
    

    Minor: All of these are comma splices. Also, we should probably mention that it's setting no limit. (Same for the rest of the SimpleTest tests.)

  3. +++ b/core/modules/simpletest/src/Tests/SimpleTestTest.php
    @@ -212,6 +219,14 @@ function stubTest() {
    +    // Getting the front page will result in a redirect to /user/2.
    
    @@ -250,7 +265,12 @@ function confirmStubTestResults() {
    +    $this->assertAssertion('exceeded acceptable maximum (1M) on url ' . User::load(2)->urlInfo()->setAbsolute()->toString(), 'Other', 'Fail', 'WebTestBase.php', 'Drupal\simpletest\WebTestBase->curlExec()');
    

    Is there any risk of the UID being something other than 2 depending on the testrunner or particular storage etc.? This didn't seem worth blocking the patch on and I assume @alexpott would have thought of that, but asking just in case.

  4. +++ b/core/modules/simpletest/src/WebTestBase.php
    @@ -62,6 +63,20 @@
    +   * Set to the maximum number of MB of memory usage to allow on the child site.
    

    I think we can drop the "Set to" since this is a property.

  5. +++ b/core/modules/simpletest/src/WebTestBase.php
    @@ -62,6 +63,20 @@
    +   * DRUPAL_MINIMUM_PHP_MEMORY_LIMIT. This value should either be equal or less
    

    So here, I'd suggest: this default value. It's confusing on first read.

  6. +++ b/core/modules/simpletest/src/WebTestBase.php
    @@ -62,6 +63,20 @@
    +   * this the module should add a check to its hook_requirements and use the
    +   * higher value in it's tests. The check can be disabled for a specific test
    

    Minor fixes: parens on hook_requirements() and use the correct "its".

  7. +++ b/core/modules/simpletest/src/WebTestBase.php
    @@ -1399,6 +1414,13 @@ protected function curlHeaderCallback($curlHandler, $header) {
    +        '@site_usage' => format_size($matches[1]),
    

    Non-actionable remark: Interesting that this function isn't a part of Bytes.

I can fix these things when I commit the patch (later this evening), or someone can reroll with them in the meanwhile.

xjm’s picture

Assigned: alexpott » Unassigned
FileSize
10.1 KB
5.58 KB

Actually holding off on committing now because HEAD is timing out on miscellaneous bots; see #2500067: Repeated HEAD failures on multiple bots with apparent 60 min timeout.

Attached fixes the docs nitpitcks. Leaving at RTBC because docs nitpicks.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 75: simpletest-2495411-75.patch, failed testing.

alexpott’s picture

The fails above are:

Test name Pass Fail Exception
CollapsedDrupal\config\Tests\ConfigImportAllTest 1210 23 0
Message Group Filename Line Function Status
Child site memory usage (64 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (64.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (64.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (64 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (65 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (65 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (66.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (73.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (66 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (66 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (66.5 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (66.75 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (66.75 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (68.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (69 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (68.5 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (68.75 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (68.75 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (70 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (69.5 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (70.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (69.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (66 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/batch?id=4&op=... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
ExpandDrupal\locale\Tests\LocaleConfigTranslationTest 147 1 0
Message Group Filename Line Function Status
Child site memory usage (79.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/admin/modules Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
ExpandDrupal\system\Tests\Installer\InstallerTranslationMultipleLanguageForeignTest 123 1 0
Message Group Filename Line Function Status
Child site memory usage (79 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/admin/modules Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
ExpandDrupal\system\Tests\Installer\InstallerTranslationMultipleLanguageKeepEnglishTest 108 1 0
Message Group Filename Line Function Status
Child site memory usage (78.5 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/admin/modules Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
ExpandDrupal\system\Tests\Module\InstallUninstallTest 1514 4 0
Message Group Filename Line Function Status
Child site memory usage (76.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/admin/modules Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (68.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/admin/modules/... Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (100 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/admin/modules Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()
Child site memory usage (72.25 MB) exceeded acceptable maximum (64M) on url http://ec2-54-85-104-252.compute-1.amazonaws.com/checkout/admin/modules Other WebTestBase.php 1355 Drupal\simpletest\WebTestBase->curlExec()

xjm’s picture

Did head regress or is there something wrong with the bots? Is this too fragile?

alexpott’s picture

@xjm not entirely sure - which is why I documented with tests failed. I was happily surprised originally when ConfigImportAll was not affected by this change.

catch’s picture

How likely is it we have a bot with no opcode cache enabled? That could definitely make the difference.

I'm running InstallUninstall test locally - although had to up my max_execution_time to 60 seconds so far since it fails with 30. If I can get it to finish, then I'll see what the memory usage looks like...

catch’s picture

InstallUninstall and ConfigImportAll both pass on my machine with the patch applied, so I suspect lack of opcode cache.

That would also explain otherwise similar bots taking 60 minutes instead of 30 minutes.

Fabianx’s picture

#82: Oh, _that_ could indeed be. But why would APC tests pass on those bots then? Or don't we have any tests needing APC(u) anymore?

catch’s picture

Those tests just don't run at the moment:

/**
 * Tests the APCu cache backend.
 *
 * @group Cache
 * @requires extension apc
 */
class ApcuBackendUnitTest extends GenericCacheBackendUnitTestBase {

  protected function checkRequirements() {
    $requirements = parent::checkRequirements();
    if (!extension_loaded('apc')) {
      $requirements[] = 'APC extension not found.';
    }
    else {
      if (version_compare(phpversion('apc'), '3.1.1', '<')) {
        $requirements[] = 'APC extension must be newer than 3.1.1 for APCIterator support.';
      }
      if (PHP_SAPI === 'cli' && !ini_get('apc.enable_cli')) {
        $requirements[] = 'apc.enable_cli must be enabled to run this test.';
      }
    }
    return $requirements;
  }

  protected function createCacheBackend($bin) {
    return new ApcuBackend($bin, $this->databasePrefix, \Drupal::service('cache_tags.invalidator.checksum'));
  }

  protected function tearDown() {
    foreach ($this->cachebackends as $bin => $cachebackend) {
      $this->cachebackends[$bin]->removeBin();
    }
    parent::tearDown();
  }

}

alexpott’s picture

I don't think this is the case. One of the passes here says we have 149 passes in this test - see https://qa.drupal.org/pifr/test/1072383

I think the Amazon infrastructure was choking on IOPs.

The last submitted patch, 75: simpletest-2495411-75.patch, failed testing.

Fabianx’s picture

#85: How does a 21 min run give any indication why the above test-run failed that you documented?

alexpott’s picture

Fabianx’s picture

I checked that locally and yes without APC(u) the test chokes ...

Only explanation could be that we trashed APC somehow (e.g. if it just has 32 MB or such in total), re-testing for now.

The last submitted patch, 75: simpletest-2495411-75.patch, failed testing.

Fabianx’s picture

/admin/modules failed now ... Seems that has regressed ...

The last submitted patch, 2: memory-usage-trigger-2495411.p1.patch, failed testing.

isntall queued 33: 2495411.33.patch for re-testing.

isntall queued 35: 2495411.patch for re-testing.

isntall queued 37: 2495411-37.patch for re-testing.

isntall queued 41: 2495411-39.patch for re-testing.

isntall queued 43: 2495411-39.patch for re-testing.

isntall queued 62: 2495411-test.62.patch for re-testing.

The last submitted patch, 37: 2495411-37.patch, failed testing.

The last submitted patch, 41: 2495411-39.patch, failed testing.

The last submitted patch, 75: simpletest-2495411-75.patch, failed testing.

The last submitted patch, 12: memory-usage-trigger-2495411.12.patch, failed testing.

The last submitted patch, 62: 2495411-test.62.patch, failed testing.

The last submitted patch, 33: 2495411.33.patch, failed testing.

The last submitted patch, 35: 2495411.patch, failed testing.

The last submitted patch, 43: 2495411-39.patch, failed testing.

xjm’s picture

Holy mothballs.

catch queued 75: simpletest-2495411-75.patch for re-testing.

The last submitted patch, 75: simpletest-2495411-75.patch, failed testing.

Fabianx’s picture

Issue tags: +Needs reroll
almaudoh’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
10.08 KB

Easy re-roll ;)

Status: Needs review » Needs work

The last submitted patch, 115: simpletest-2495411-115.patch, failed testing.

xjm’s picture

Huh, why are the PIFR results so different from the DrupalCI results on #115?

jthorson’s picture

@xjm: See #2532268: DrupalCI test results show wildly different numbers of passes/fails than PIFT/PIFR ... DrupalCI reports test results, not individual assertion results ... a new paradigm for sure, but it should result in more consistent test counts between individual test runs.

alexpott’s picture

re #118 that's not the case here - only 1 test class has fails on DrupalCI whereas 6 classes have on testbots-of-yore

Mixologic’s picture

Yes, this looks like a case where the new testbots arent actually using enough memory to trigger the fail. Can we add some debug assertions to the patch to see what the actual values are in those tests?

Mixologic’s picture

I wonder if this is related to the fact that the drupalci testbots might be entirely fresh vs the legacy bots that have been around for weeks.

catch’s picture

The last submitted patch, 122: simpletest-2495411-48M.patch, failed testing.

The last submitted patch, 122: simpletest-2495411-32M.patch, failed testing.

The last submitted patch, 122: simpletest-2495411-40M.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 122: simpletest-2495411-56M.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
10.08 KB

Status: Needs review » Needs work

The last submitted patch, 127: simpletest-2495411-63M.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
10.08 KB

So 63M looks like what DrupalCi is using. That isn't consistent with PIFR now, but it's very close to what it was when this patch was RTBC in #72 - we were just under at that time.

I'm assuming the PIFR issues are something to do with PHP configuration - although I think we ruled out opcache being full/fragmented already which is the only obvious issue.

However it's also concerning that the SimpletestTest which sets this to 1M doesn't pass - suggests something broken in the running of that test.

Seeing if we can get PIFR to pass at all now.

Status: Needs review » Needs work

The last submitted patch, 129: simpletest-2495411-100M.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
10.08 KB

Status: Needs review » Needs work

The last submitted patch, 131: simpletest-2495411-110M.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
2.08 KB
11.6 KB

Fixed SimpletestTest and I think the differences between DrupalCI and pifr can be explained by DrupalCI being slower and therefore doing less each batch step. We can check memory usage on progressive batches to try to make the environments perform the same.

This also explains why this was working on pifr when it had slower bots.

Status: Needs review » Needs work

The last submitted patch, 133: 2495411-2.133.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
899 bytes
11.6 KB

Let's go to 60%

Status: Needs review » Needs work

The last submitted patch, 135: 2495411-2.135.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
11.6 KB

Or 40%, but I start to wonder if the bigger operations within batches is the only issue.

Status: Needs review » Needs work

The last submitted patch, 137: 2495411-2.137.patch, failed testing.

Status: Needs work » Needs review

effulgentsia queued 137: 2495411-2.137.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 137: 2495411-2.137.patch, failed testing.

effulgentsia’s picture

Status: Needs work » Needs review
FileSize
11.6 KB
870 bytes

Running a similar experiment as #122: i.e., setting the limit to 32M to compare differences between pifr and DrupalCI.

Status: Needs review » Needs work

The last submitted patch, 141: 2495411-2.137-32M.patch, failed testing.

effulgentsia’s picture

I'm assuming the PIFR issues are something to do with PHP configuration - although I think we ruled out opcache being full/fragmented already which is the only obvious issue.

Running these tests locally, I get the same memory numbers for CommentFieldsTest as PIFR (53 MB) when I have opcache disabled (with or without apcu.so enabled) and nearly the same numbers as DCI (I get 30MB whereas DCI shows 32.5MB) when I have opcache enabled (with or without apcu.so enabled). Are we sure that PIFR has a functioning opcache? Or does it only have apcu, which isn't an opcode cache?

Mixologic’s picture

The PIFR Bots have opcache running and its functional - I ran this from an existing bot, and saved it to a dev site so it could be seen:
https://drupal:drupal@mixologic-ci-drupal.redesign.devdrupal.org/opcache...

catch’s picture

Is opcode.max_accelerated_files to low?

Is set to 2000.

3,905 scripts are cached.

http://php.net/manual/en/opcache.configuration.php#ini.opcache.max-accel... says the real maximum when set to 2000 will be 3907

This would also explain why the output says it's full, when there is plenty of space.

catch’s picture

I've opened #2551309: Increase opcache.max_accelerated_files to track this somewhere other than this issue.

The last submitted patch, 127: simpletest-2495411-63M.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
11.6 KB

Reviving this now that PIFR is disabled.

catch’s picture

The last submitted patch, 149: 2495411-149-64M.patch, failed testing.

alexpott’s picture

Status: Needs review » Needs work
+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -64,6 +65,20 @@
   /**
+   * The maximum memory usage to allow on the child site, in MB.
+   *
+   * The minimum amount of memory Drupal expects to have available is defined by
+   * DRUPAL_MINIMUM_PHP_MEMORY_LIMIT. This default value on the base class
+   * should be less than or equal to DRUPAL_MINIMUM_PHP_MEMORY_LIMIT. If a
+   * module requires more memory than this limit, the module should add a
+   * check to its hook_requirements() and use the higher value in its tests.
+   * The check can be disabled for a specific test by setting it to FALSE.
+   *
+   * @var string|FALSE
+   */
+  protected $memoryUsageTrigger = '32M';

You need to change this too... I think we should have a constant so we only have to configure this once... it can't be in Simpletest as that won;t be available in child sites but one constant in ./core won't hurt... maybe on \Drupal

The last submitted patch, 150: 2495411-149-96M.patch, failed testing.

catch’s picture

Good point. Added the constant.

Status: Needs review » Needs work

The last submitted patch, 154: 2495411-154.patch, failed testing.

The last submitted patch, 154: 2495411-154.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
2.44 KB
18.36 KB

Fixing the test fail. Also the new constant is only about simpletest and therefore should be named that way.

catch’s picture

Not sure we should name it simpletest, we could potentially do the same treatment on browser tests. Just TEST something might be fine though.

alexpott’s picture

Hmmm I'm also not sure we're doing the batch limit right - I think we need to be able to send the memory limit to the child site so tests can alter it.

Status: Needs review » Needs work

The last submitted patch, 159: 2495411-3-159.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
837 bytes
15.98 KB

Fixing tests - we still need to make BrowserTestBase tests fail when the memory limit has been exceeded.

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.

lokapujya’s picture

Issue tags: +Needs reroll
lokapujya’s picture

Reroll Attempt.

Status: Needs review » Needs work

The last submitted patch, 164: 2495411-163.patch, failed testing.

lokapujya’s picture

Fail :(

Something to work on at the sprint.

lokapujya’s picture

Status: Needs work » Needs review
FileSize
14.33 KB

Merging BrowserTestBase conflicts is a little complicated.

Status: Needs review » Needs work

The last submitted patch, 167: 2495411-167.patch, failed testing.

Fabianx’s picture

Too bad this is not yet in :/.

Mixologic’s picture

Issue tags: +drupalci_environments
Mile23’s picture

Version: 8.1.x-dev » 8.2.x-dev
Status: Needs work » Needs review
FileSize
14.36 KB

Reroll of #167.

Status: Needs review » Needs work

The last submitted patch, 171: 2495411_171.patch, failed testing.

Mile23’s picture

Status: Needs work » Needs review

Testing against the wrong core version...

Status: Needs review » Needs work

The last submitted patch, 171: 2495411_171.patch, failed testing.

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

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.