Behat PHP version

[maskedjellybean]

In pantheon.yml I have php_version: 7.4. It appears this is NOT the version used when running Behat tests against a Pantheon multidev. As far as I can tell, Behat somehow uses < 7.1.

The behat_test job consistently fails due to this property in a Behat context class:

  /**
   * @var self|null
   */
  private static ?GroupManager $instance = NULL;

The error is:

+ ./vendor/bin/behat --config=tests/behat/behat-pantheon.yml --strict --colors
@api
Feature: Check that groups and their respective fields exist and are as expected.

Parse error: syntax error, unexpected '?', expecting function (T_FUNCTION) or const (T_CONST) in /home/tester/example_drops_8_composer/tests/behat/features/bootstrap/GroupManager.php on line 15

My understanding is that this is called a nullable type, and it was introduced in PHP 7.1: https://www.php.net/manual/en/migration71.new-features.php

I can say when running tests locally using 7.4, this error does not occur. So how and where is the PHP version used for Behat running against Pantheon configured? Sorry if I'm way off base here, but this is the only conclusion I can come to.

[maskedjellybean]

Digging deeper, maybe it runs using PHP 7.3? https://quay.io/repository/pantheon-public/build-tools-ci/manifest/sha256:2cebe0db5c0cf5682ad14fa28550435a402425d2c9ef3c000e343db62ad93fde

[maskedjellybean]

Ok! Got it!

If at the top of your ./.circleci/config.yml you see:

defaults: &defaults
  docker:
    - image: quay.io/pantheon-public/build-tools-ci:6.x

Then your jobs are running using PHP 7.3.

You could either change the default image to one of these: https://quay.io/repository/pantheon-public/build-tools-ci

Or change the image for specific job like:

  behat_test:
    <<: *defaults
    docker:
      - image: quay.io/pantheon-public/build-tools-ci:8.x-php7.4

Now my tests are running. Some are failing with a new error:

\Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container. (Drupal\Core\DependencyInjection\ContainerNotInitializedException)

But this is probably a separate issue.

[greg-1-anderson]

Run build:project:create to build a new site, and compare the result with your site. There are probably some script changes that you need to make when moving from the 6.x build-tools-ci image to the 8.x image.

[greg-1-anderson]

Or just look at example-drops-8-composer

[maskedjellybean]

Thanks Greg! Can you explain the difference between 6.x and 8.x? I'm assuming they're not referencing Drupal versions. The last time I ran build:project:create was probably a couple months ago and that's what gave me the 6.x config. Would setting the version to 7.4.x instead of 8.x-php7.4 be less of a jump?

[greg-1-anderson]

Just grabbing arbitrary tags from the docker image is not a good idea. Some of them were made by mistake (pre-releases that shouldn't have been released) and never supported. We can't ever remove them, though, because sometimes people look at the tags and decide to use them, so we break builds if they go away.

The basic idea is that build:project:create uses the most recent version of the docker image. If we ever need to make a change to the docker image, and that change is not backwards-compatible with all of the existing Build Tools sites, then we bump the major version of the image up, and make the example templates start using the new images. There is no maintained migration path from one branch to the next. Going up to anything other than the most recent version of the docker image is going to be a lot harder, as you'd have to go back and figure out which old version of the template uses it. The best bet is to look at the most recent version of the template project, and mirror what it is doing.