diff --git a/CHANGELOG.md b/CHANGELOG.md
index 6d78a1637d5db47eddf9e27de83771fa2bec7a3a..70c8e0312e2c70a97e8716790ccf5efcdf147f43 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,7 @@
+## 3.7.0
+* Many changes to internal testing infrastructure, but nothing that
+ should affect users of Lightning Workflow.
+
## 3.6.0
* Fixed a bug that could occur with Drupal 8.7 when installing the
moderation_history view.
diff --git a/modules/lightning_scheduler/tests/features/transitions.feature b/modules/lightning_scheduler/tests/features/transitions.feature
index 1b33f8e2ff2528fc16a403d7922cd610e22ddb08..bd0cf2ed9b57d6670ecb949eceb3b4b736603676 100644
--- a/modules/lightning_scheduler/tests/features/transitions.feature
+++ b/modules/lightning_scheduler/tests/features/transitions.feature
@@ -1,7 +1,7 @@
@api @lightning @lightning_workflow @lightning_scheduler
Feature: Scheduling transitions on content
- @368f0045 @javascript @orca_public
+ @368f0045 @javascript
Scenario: Automatically publishing, then unpublishing, in the future
Given I am logged in as a user with the "create page content, view own unpublished content, edit own page content, use editorial transition create_new_draft, use editorial transition review, use editorial transition publish, use editorial transition archive, schedule editorial transition publish, schedule editorial transition archive, view latest version, administer nodes" permissions
When I visit "/node/add/page"
diff --git a/settings.local.php b/settings.local.php
new file mode 100644
index 0000000000000000000000000000000000000000..a1ecab9c7eed569e36047c266bc73a1a2f78f0bf
--- /dev/null
+++ b/settings.local.php
@@ -0,0 +1,145 @@
+<?php
+
+// @codingStandardsIgnoreFile
+
+/**
+ * @file
+ * Local development override configuration feature.
+ *
+ * To activate this feature, copy and rename it such that its path plus
+ * filename is 'sites/default/settings.local.php'. Then, go to the bottom of
+ * 'sites/default/settings.php' and uncomment the commented lines that mention
+ * 'settings.local.php'.
+ *
+ * If you are using a site name in the path, such as 'sites/example.com', copy
+ * this file to 'sites/example.com/settings.local.php', and uncomment the lines
+ * at the bottom of 'sites/example.com/settings.php'.
+ */
+
+/**
+ * Assertions.
+ *
+ * The Drupal project primarily uses runtime assertions to enforce the
+ * expectations of the API by failing when incorrect calls are made by code
+ * under development.
+ *
+ * @see http://php.net/assert
+ * @see https://www.drupal.org/node/2492225
+ *
+ * If you are using PHP 7.0 it is strongly recommended that you set
+ * zend.assertions=1 in the PHP.ini file (It cannot be changed from .htaccess
+ * or runtime) on development machines and to 0 in production.
+ *
+ * @see https://wiki.php.net/rfc/expectations
+ */
+assert_options(ASSERT_ACTIVE, TRUE);
+\Drupal\Component\Assertion\Handle::register();
+
+/**
+ * Enable local development services.
+ */
+$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';
+
+/**
+ * Show all error messages, with backtrace information.
+ *
+ * In case the error level could not be fetched from the database, as for
+ * example the database connection failed, we rely only on this value.
+ */
+$config['system.logging']['error_level'] = 'verbose';
+
+/**
+ * Disable CSS and JS aggregation.
+ */
+$config['system.performance']['css']['preprocess'] = FALSE;
+$config['system.performance']['js']['preprocess'] = FALSE;
+
+/**
+ * Disable the render cache.
+ *
+ * Note: you should test with the render cache enabled, to ensure the correct
+ * cacheability metadata is present. However, in the early stages of
+ * development, you may want to disable it.
+ *
+ * This setting disables the render cache by using the Null cache back-end
+ * defined by the development.services.yml file above.
+ *
+ * Only use this setting once the site has been installed.
+ */
+# $settings['cache']['bins']['render'] = 'cache.backend.null';
+
+/**
+ * Disable caching for migrations.
+ *
+ * Uncomment the code below to only store migrations in memory and not in the
+ * database. This makes it easier to develop custom migrations.
+ */
+# $settings['cache']['bins']['discovery_migration'] = 'cache.backend.memory';
+
+/**
+ * Disable Internal Page Cache.
+ *
+ * Note: you should test with Internal Page Cache enabled, to ensure the correct
+ * cacheability metadata is present. However, in the early stages of
+ * development, you may want to disable it.
+ *
+ * This setting disables the page cache by using the Null cache back-end
+ * defined by the development.services.yml file above.
+ *
+ * Only use this setting once the site has been installed.
+ */
+# $settings['cache']['bins']['page'] = 'cache.backend.null';
+
+/**
+ * Disable Dynamic Page Cache.
+ *
+ * Note: you should test with Dynamic Page Cache enabled, to ensure the correct
+ * cacheability metadata is present (and hence the expected behavior). However,
+ * in the early stages of development, you may want to disable it.
+ */
+# $settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
+
+/**
+ * Allow test modules and themes to be installed.
+ *
+ * Drupal ignores test modules and themes by default for performance reasons.
+ * During development it can be useful to install test extensions for debugging
+ * purposes.
+ */
+# $settings['extension_discovery_scan_tests'] = TRUE;
+
+/**
+ * Enable access to rebuild.php.
+ *
+ * This setting can be enabled to allow Drupal's php and database cached
+ * storage to be cleared via the rebuild.php page. Access to this page can also
+ * be gained by generating a query string from rebuild_token_calculator.sh and
+ * using these parameters in a request to rebuild.php.
+ */
+$settings['rebuild_access'] = TRUE;
+
+/**
+ * Skip file system permissions hardening.
+ *
+ * The system module will periodically check the permissions of your site's
+ * site directory to ensure that it is not writable by the website user. For
+ * sites that are managed with a version control system, this can cause problems
+ * when files in that directory such as settings.php are updated, because the
+ * user pulling in the changes won't have permissions to modify files in the
+ * directory.
+ */
+$settings['skip_permissions_hardening'] = TRUE;
+
+$settings['bootstrap_container_definition'] = [
+ 'parameters' => [],
+ 'services' => [
+ 'database' => [
+ 'class' => 'Drupal\Core\Database\Connection',
+ 'factory' => 'Drupal\Core\Database\Database::getConnection',
+ 'arguments' => ['default'],
+ ],
+ 'cache.container' => [
+ 'class' => 'Drupal\Core\Cache\MemoryBackend',
+ ],
+ ],
+];
diff --git a/tests/fixtures/3.7.0.php.gz b/tests/fixtures/3.7.0.php.gz
new file mode 100644
index 0000000000000000000000000000000000000000..22a1f0ccd82ff787cb2c7f8bf87a9c697eda42cb
Binary files /dev/null and b/tests/fixtures/3.7.0.php.gz differ