Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Fatal error: Class 'Craft' not found" when running tests on CircleCI #5164

Closed
dce opened this issue Oct 24, 2019 · 17 comments
Closed

"Fatal error: Class 'Craft' not found" when running tests on CircleCI #5164

dce opened this issue Oct 24, 2019 · 17 comments
Assignees
Labels
testing ✅ features related to testing

Comments

@dce
Copy link

dce commented Oct 24, 2019

Description

I have a test suite that runs in my local Docker environment, and I'm trying to get it running on CircleCI. Trouble is, no matter what I try, I get some variant of this error:

./vendor/bin/codecept run
Codeception PHP Testing Framework v3.0.2
Powered by PHPUnit 7.5.13 by Sebastian Bergmann and contributors.
Running with seed: 


Acceptance Tests (0) ---------------------------------------
------------------------------------------------------------

Fatal error: Class 'Craft' not found in /home/circleci/project/vendor/codeception/codeception/src/Codeception/Lib/Di.php on line 84

Call Stack:
    0.0001     378456   1. {main}() /home/circleci/project/vendor/codeception/codeception/codecept:0
    0.0599    8944400   2. Codeception\Application->run() /home/circleci/project/vendor/codeception/codeception/codecept:43
    0.0599    8944400   3. Codeception\Application->run() /home/circleci/project/vendor/codeception/codeception/src/Codeception/Application.php:107
    0.0663    9109568   4. Codeception\Application->doRun() /home/circleci/project/vendor/symfony/console/Application.php:149
    0.0666    9113136   5. Codeception\Application->doRunCommand() /home/circleci/project/vendor/symfony/console/Application.php:273
    0.0667    9113136   6. Codeception\Command\Run->run() /home/circleci/project/vendor/symfony/console/Application.php:934
    0.0670    9116552   7. Codeception\Command\Run->execute() /home/circleci/project/vendor/symfony/console/Command/Command.php:255
    0.0820   10186944   8. Codeception\Command\Run->runSuites() /home/circleci/project/vendor/codeception/codeception/src/Codeception/Command/Run.php:391
    0.1072   12089368   9. Codeception\Codecept->run() /home/circleci/project/vendor/codeception/codeception/src/Codeception/Command/Run.php:496
    0.1080   12092568  10. Codeception\Codecept->runSuite() /home/circleci/project/vendor/codeception/codeception/src/Codeception/Codecept.php:160
    0.1080   12092824  11. Codeception\SuiteManager->__construct() /home/circleci/project/vendor/codeception/codeception/src/Codeception/Codecept.php:188
    0.1081   12093864  12. Codeception\Lib\ModuleContainer->create() /home/circleci/project/vendor/codeception/codeception/src/Codeception/SuiteManager.php:67
    0.1092   12293544  13. Codeception\Lib\Di->instantiate() /home/circleci/project/vendor/codeception/codeception/src/Codeception/Lib/ModuleContainer.php:92
    0.1092   12293832  14. ReflectionClass->newInstanceArgs() /home/circleci/project/vendor/codeception/codeception/src/Codeception/Lib/Di.php:84




FATAL ERROR. TESTS NOT FINISHED.
Class 'Craft' not found 
in /home/circleci/project/vendor/codeception/codeception/src/Codeception/Lib/Di.php:84
Exited with code 255

The issue seems connected to the references to craft\test\Craft in codeception.yml, test/functional.suite.yml and test/unit.suit.yml -- if I remove those, the error goes away (and new ones appear, of course).

This is almost certainly an issue with my code/config and not Craft, but I'm curious if anyone else has encountered anything like this. Thank you.

Steps to reproduce

  1. .circleci/config.yml:
version: 2

jobs:
  build:
    docker:
      - image: circleci/php:7.1-node-browsers
      - image: mariadb:10.3
        environment:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: clientname
          MYSQL_USER: clientname
          MYSQL_PASSWORD: clientname
    steps:
      - checkout
      - run: sudo apt update
      - run: sudo apt install libpng-dev
      - run: sudo docker-php-ext-install gd pdo_mysql
      - restore_cache:
          keys:
            - composer-{{ checksum "composer.lock" }}
      - run: composer install
      - save_cache:
          paths:
            - vendor
          key: composer-{{ checksum "composer.lock" }}
      - run: cp .circleci/.env tests
      - run: ./vendor/bin/codecept run
  1. codeception.yml
actor: Tester
paths:
    tests: tests
    log: tests/_output
    data: tests/_data
    support: tests/_support
    envs: tests/_envs
bootstrap: _bootstrap.php
params:
    - tests/.env
modules:
    config:
        \craft\test\Craft:
            configFile: 'tests/_craft/config/test.php'
            entryUrl: 'http://clientname.test/index.php'
            entryScript: ''
            projectConfig: {file: 'config/project.yaml'}
            migrations: []
            plugins: []
            cleanup: true
            transaction: true
            dbSetup: {clean: true, setupCraft: true}

Not sure what other info is relevant but happy to provide anything.

Additional info

  • Craft version: 3.3.7
  • PHP version: 7.1
  • Database driver & version: MariaDB 10.3
  • Plugins & versions:
  3     "clubstudioltd/craft-asset-rev": "6.0.2",
  4     "craftcms/cms": "3.3.7",
  5     "craftcms/redactor": "2.4.0",
  6     "dolphiq/redirect": "1.0.23",
  7     "rias/craft-width-fieldtype": "1.0.6",
  8     "shennyg/azure-blob-remote-volume": "1.0.2",
  9     "solspace/craft3-calendar": "2.0.24",
 10     "verbb/navigation": "1.1.13",
 11     "verbb/super-table": "2.3.0",
 12     "viget/craft-video-embed": "^1.2",
 13     "vlucas/phpdotenv": "^3.4"
@angrybrad angrybrad self-assigned this Oct 24, 2019
@angrybrad angrybrad added the testing ✅ features related to testing label Oct 24, 2019
@gtettelaar
Copy link
Contributor

gtettelaar commented Oct 25, 2019

Do these tests run locally? Also what does your tests/_craft/config/test.php & tests/_bootstrap.php files look like?

@dce
Copy link
Author

dce commented Oct 25, 2019

Yes, they run properly in the local Docker environment I use for development.

tests/_craft/config/test.php:

<?php
use craft\test\TestSetup;

return TestSetup::createTestCraftObjectConfig();

tests/_bootstrap.php:

<?php

use craft\test\TestSetup;

ini_set('date.timezone', 'UTC');

// Use the current installation of Craft
define('CRAFT_STORAGE_PATH', __DIR__ . '/_craft/storage');
define('CRAFT_TEMPLATES_PATH', dirname(__DIR__) . '/templates');
define('CRAFT_CONFIG_PATH', __DIR__ . '/_craft/config');
define('CRAFT_MIGRATIONS_PATH', __DIR__ . '/_craft/migrations');
define('CRAFT_TRANSLATIONS_PATH', __DIR__ . '/_craft/translations');
define('CRAFT_VENDOR_PATH', dirname(__DIR__).'/vendor');

TestSetup::configureCraft();

@gtettelaar
Copy link
Contributor

Hmm that looks all normal. If you can share your unit.suite.yaml and functional.suite.yaml I can try to reproduce it locally...

@dce
Copy link
Author

dce commented Oct 25, 2019

# Codeception Test Suite Configuration
#
# Suite for unit or integration tests.

actor: UnitTester
modules:
    enabled:
        - \craft\test\Craft
        - Asserts
        - \Helper\Unit
    step_decorators: ~
# Codeception Test Suite Configuration
#
# Suite for functional tests
# Emulate web requests and make application process them
# Include one of framework modules (Symfony2, Yii2, Laravel5) to use it
# Remove this suite if you don't use frameworks

actor: FunctionalTester
modules:
    enabled:
        - \craft\test\Craft
        - \Helper\Functional
    step_decorators: ~

@dce
Copy link
Author

dce commented Oct 25, 2019

Yeah, it's bewildering. My first thought was some kind of case sensitivity issue going from macOS to Linux, but since I'm running in Docker locally, I think I've squashed all of those issues.

@gtettelaar
Copy link
Contributor

gtettelaar commented Oct 25, 2019

Looks like it's related to your codeception version. You are using 3.0.2 however the way you defined the bootstrap (bootstrap: _bootstrap.php) file is allowed only from ^3.1.0 so it wasn't loading tests/_bootstrap.php, this would result in the Craft file not being loaded and then the whole thing will just explode.....

See the discussion around #4772 - Craft's Travis CI ran into the same problem. Can you try adding "codeception/codeception": "^3.1.0" to your composer.json file to see if that fixes it?

@dce
Copy link
Author

dce commented Oct 27, 2019

@gtettelaar this does appear to have fixed the issue. Thanks for all your help! I can go ahead and close this out unless you or someone on the team would prefer to.

@gtettelaar
Copy link
Contributor

@dce Good to hear! Went ahead and closed it for you.

@angrybrad Do you have an idea of how through for example composer to require a minimum of ^3.1.0 without having it be shipped with every Craft project on composer install - or some other way to prevent this issue from recurring?

@angrybrad
Copy link
Member

@gtettelaar hrm... not sure. We started requiring Codeception 3.1 since Craft 3.3.1, so I'm assuming this was an upgraded install from pre 3.3.1.

A bit hacky, but maybe we could do some Codeception version number checking in our test config/bootstrap and bail if it's pre 3.1 with a message saying to update?

@narration-sd
Copy link
Contributor

@angrybrad help out a cross-fields refugee. What is 'hacky' about such a decent check?? Trying to understand meaning of that term...srsly

@gtettelaar
Copy link
Contributor

@angrybrad Yea but require-dev only works when using Craft as the root project. If you do composer update --dev then a Craft site won't automatically take over that dependency - you could still use version 3.0.0 of Codeception without Composer throwing a conflict error post Craft 3.3.1.

A bit hacky, but maybe we could do some Codeception version number checking in our test config/bootstrap and bail if it's pre 3.1 with a message saying to update?

The testing framework (craft\test\Craft) isn't touched during the occurrence of this error so where would we place that check?

@narration-sd
Copy link
Contributor

@angrybrad Brad, never mind -- it's Monday and we are all busy. It is a sort of recurring question, though, if of course I probably understand one or more answers. Not everything being solvable by elegant algorithmic patterns, up front ... 😎🐟

@gtettelaar
Copy link
Contributor

@angrybrad What about Composer's conflict option?

@angrybrad
Copy link
Member

angrybrad commented Oct 28, 2019

@gtettelaar possible as a workaround... i've never used that before. Outside of conflict, does this seem like something Codeception should be checking for?

@narration-sd hacky was probably the wrong word. more like not the most desirable option.

@narration-sd
Copy link
Contributor

narration-sd commented Oct 28, 2019

@gtettelaar from the peanut gallery, conflict does seem a possibly nicer solution, in that it puts the condition out front where it's visible. And given conflict actually does what it seems to say.

The downside may be that you'd get one of those 'something doesn't match your conditions' null-reports from Composer, where the scripted block would report very clearly. I guess you'll find best by trying it. And I will keep quiet! But interested.

@angrybrad ++thanks, Brad

@gtettelaar
Copy link
Contributor

does this seem like something Codeception should be checking for?

Just thinking about it - this bug is really caused by Codeception. If you configure it incorrectly (use bootstrap: _bootstrap.php on 3.0.0) then obviously Craft won't work but neither will any of your tests if you weren't using a custom (Codeception)module.

I'll PR a 'fix' for the docs to make this more explicit but I don't see a nice way of solving this without jumping through hoops that worsen the codebase in an effort to fix an edge case. Honestly, the few people running into this will probably find this issue and the problem will be resolved for them.

Regarding conflict, I know I suggested it but it's not a good solution. Indicating Craft conflicts with Codeception 3.0.0 is wrong - the testing framework works fine on 3.0.0 it just needs different configuration settings. We shouldn't prevent the usage of 3.0.0...

@angrybrad
Copy link
Member

@gtettelaar cool, agreed about the edge-casiness. I think given enough time this will sort of work itself out, anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
testing ✅ features related to testing
Projects
None yet
Development

No branches or pull requests

4 participants