Add GitLab CI testing on 7.x

It seems like testing with Drupal 7 on GitLab CI is not yet ready
#3343810: Support for testing Drupal 7 with the template →

Patch for core debug.

Breakthrough! I removed the 'date' and 'date_pop' modules from the Date test, and the Scheduler permissions were then properly available. It was an obvious thing to try, in hindsight, but things are always simple afterwards. Clearly this is not the solution, because the tests now fail due to not having the Date module. But we can now investigate what Date is doing.

Here's a sample from the extra debug, when the Date module is enabled. It seems that Scheduler is known about in module_list() but then it becomes unknown.

ML1. module_list(), empty($list) || $refresh || $fixed_list
ML2. module_list(), from refresh
ML3. module_list(), from bootstrap_refresh
ML5. module_list() returns 'scheduler': NO
...
ML1. module_list(), empty($list) || $refresh || $fixed_list
ML2. module_list(), from refresh
ML4. module_list(), not from bootstrap_refresh
ML5. module_list() returns 'scheduler': yes
...
This is SchedulerDateModuleTest::setUp()
calling parent::setUp('date', 'date_popup','scheduler')
This is DrupalWebTestCase::setUp()
ML5. module_list() returns 'scheduler': yes
ML5. module_list() returns 'scheduler': yes
ML1. module_list(), empty($list) || $refresh || $fixed_list
ML2. module_list(), from refresh
ML4. module_list(), not from bootstrap_refresh
ML5. module_list() returns 'scheduler': NO
in module_implements(), resetting ...
ML1. module_list(), empty($list) || $refresh || $fixed_list
ML4. module_list(), not from bootstrap_refresh
ML5. module_list() returns 'scheduler': NO

From this point onwards, module_list returns 'scheduler' so the permissions are not returned, even though the module is konwn, enabled and we get function scheduler_permission exists in the debug log.

This is great! Sometimes it's the most unexpected!

Trying patch from #2763435: Exceptions during the setUp() or tearDown() method of a test are not handled → . The rendered markup comes because even if "parent::setUp" triggered an error, the "test..." method is still trying to be run. It just doesn't seem to be stopping on fail.

Thanks for finding that issue and patching it here. Your commits dont seem to be triggering pipelines.

I identified the source of the main issue (html thrown and errors reported as success). Will explain further tomorrow but you can see how everything looks "as it should" in the last pipeline: https://git.drupalcode.org/issue/scheduler-3387331/-/pipelines/28836

Hint: PHP5.6 vs PHP7 handle the same error in different ways.

The fix for core is here: 🐛 Exceptions ignored in errorHandler for DrupalTestCase Fixed .

With this patch applied, you should be able to at least catch the exception when it happens and it won't try anything else or report a false positive.
There is still the issue of the permissions not being available, but that seems to be related to a combo of date, date_popup, scheduler as mentioned in #8.

I left the file "drupal_web_test_case.php" in the MR and commented out the patch with the additional output you did. I find that way easier to override things from core. Bring the file to the repo, change it at will and then override the core one via GitlabCI. That way you don't need to generate patches. In any case, that's what works for me but you can continue however it's easier for you.

This is excellent progress, thanks for taking it on.

There is still the issue of the permissions not being available, but that seems to be related to a combo of date, date_popup, scheduler as mentioned in #8.

Yes, that's a separate problem. I'm going to take that on to a new MR, and leave this MR to demonstrate the problem and fix for tests not failing.

I left the file "drupal_web_test_case.php" in the MR and commented out the patch with the additional output you did ... that's what works for me but you can continue however it's easier for you.

That's also a good way to do it. I'm happy to leave it like this.

I'm going to change the tests here, to just run two simple tests to demonstrate the problems of not failing. Hopefully these should both fail with your patch. First run will be without the patch, which should pass (incorrectly).

For the parse error, you might actually not be able to catch it (https://stackoverflow.com/questions/1900208/php-custom-error-handler-han...). Maybe playing with "shutdown" functions, but not sure how, and if possible, it'll be something to add to core D7, similar to the other issue we found.

Just to record this here, with core patched from the commit on 🐛 Exceptions ignored in errorHandler for DrupalTestCase Fixed , the login(false) exception now causes the test to fail
https://git.drupalcode.org/project/scheduler/-/pipelines/29134

Restoring this mr to contain the syntax error test. For following up the hints in #15.

Thanks to @flgarlin's work on #3392363: D7 contrib pipeline tests fail when requiring a 3rd-party contrib module → Scheduler no longer has move the loaded modules 📌 Remove custom composer after_script Fixed
So this is now fixed.

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