We are using Drupal TI to deploy on Travis but this also fails for me locally with the same error. So I do not think Drupal TI is the culprit.

PHP Fatal error:  Undefined class constant 'Symfony\Component\DependencyInjection\ContainerInterface::SCOPE_CONTAINER' in /home/travis/build/acquia/drupal-8/drupal/core/lib/Drupal/Core/DependencyInjection/Container.php on line 21
Fatal error: Undefined class constant 'Symfony\Component\DependencyInjection\ContainerInterface::SCOPE_CONTAINER' in /home/travis/build/acquia/drupal-8/drupal/core/lib/Drupal/Core/DependencyInjection/Container.php on line 21

Example: https://travis-ci.org/acquia/df/jobs/122576191#L1629

This just started happening recently, with no changes on our end that would have triggered this.

I wonder if:

a) Is anyone else seeing this too?
b) Perhaps there is a known workaround?

For reference, the entire repo is available here: https://github.com/acquia/df


brantwynn created an issue. See original summary.

jhedstrom’s picture

You need to pin the symfony version at 2.7.x (for Drupal 8.0.x) or 2.8.x for (8.1.x or 8.2.x). The reason these versions aren't pinned by this project is that, ironically, symfony 3.x can be used with Drupal 7 :)

See https://github.com/jhedstrom/drupalextension/blob/master/doc/_static/com... for an example.

brantwynn’s picture


Pinning the symfony/event-dispatcher and symfony/dependency-injection to 2.7.2 in our /tests/composer.json and then running composer update fixed this for me locally. So I am able to at least run tests again.

It would seem that updating these libs has somehow broken Migrate module, but I know we've been doing work to fix our code that uses Migrate anticipating 8.1.x changes.
(I think that is unrelated to the DrupalExtension so I won't get into it here.)

What is relevant: I see that there are some other libs not referenced in the example that download other versions.

Installing symfony/config (v2.8.4)
    Cloning 5273f4724dc5288fe7a33cb08077ab9852621f2c
Installing symfony/css-selector (v3.0.4)
    Cloning 65e764f404685f2dc20c057e889b3ad04b2e2db0

So two questions:

1. Should we be pinning all symfony/* dependencies explicitly?
2. Should we tie specifically to 2.7.2 or should we use a wildcard?

jhedstrom’s picture

In the tests for the Drupal Extension itself, I only pin the symfony components that core uses. I also pin the exact version core uses as there were actually some interface changes between 2.7.2 and 2.7.4 so if 2.7.4 is installed, and core has 2.7.2, you get errors.

steveoliver’s picture

Status: Active » Fixed

Marking this Fixed since, as @jhedstrom says, pinning those Symfony components fixes this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.