Switch functional testing to Drupal CMS only

Problem/Motivation

Educare's automated testing ran against a Varbase 11 host project: a pre-test job built Varbase, installed the checked-out recipe into it, and dumped the database for the test jobs to restore. Nothing exercised drupal/cms, which is the host the site template is aimed at, so a regression in Educare's ability to build and install on plain Drupal CMS produced a fully green pipeline.

The decision taken is to switch functional testing to Drupal CMS only, rather than run both hosts.

Steps to reproduce

Read .gitlab-ci.yml on 1.0.x: the only host build is Varbase, and every test job restores its dump. Break installing Educare on a plain drupal/cms host and the pipeline stays green.

Proposed resolution

1. Delete the Varbase host build job. drupal/cms becomes the sole host project, and VARBASE_PROJECT and the two Varbase cache anchors go with it.
2. Rename the test stage and its jobs to "functional": stage test becomes functional, and job 🧪 varbase-e2e becomes 🧪 Functional. The @vardot/varbase-e2e framework itself is unchanged — only the host changes.
3. Add "📦 (Drupal CMS) Install Educare site template" as the host build: composer create-project drupal/cms, minimum-stability dev, a path repository to the checked-out recipe, then drush site:install recipes/educare. It is the gate for the entire suite and feeds the functional jobs, so it inherits the full build — npm, the Playwright browser, the deterministic prep and the database dump. It is not the lean optional smoke test first proposed here.
4. Add a $DRUSH variable, because drupal/cms sets bin-dir: vendor/bin while the Varbase project used ./bin. The functional job's database restore, cache rebuild and runserver calls were all written for the Varbase layout and would otherwise each have broken silently.
5. Keep the path repository's "options":{"symlink":false}. A symlinked recipes/educare points back at $CI_PROJECT_DIR, which contains the build, and the recursive scan then fails with "Too many levels of symbolic links" — learned once already in the earlier Drupal CMS job added for #3614680 and removed for #3618244 with scripts/drupal-cms-wiring.php. This is the direct-recipe path, not a revert of that drupal_cms_installer plus wiring-script approach.
6. Omit script_failure from the install job's retry: while the install cannot pass, so a guaranteed failure does not burn three full builds per pipeline. Only runner_system_failure and stuck_or_timeout_failure are retried.

The install fails today, the job is allow_failure: false anyway, and the pipeline is red

Correction, added later. The diagnosis below — that this failure is a Canvas defect outside Educare and not fixable from this project — is wrong, and it was wrong when this summary was written. The real cause is that Canvas installs canvas_page_template_component lazily during RecipeAppliedEvent, and the container rebuild that triggers is what leaves kernel synthetic. Declaring that module in the recipe's own install: list fixes it in one line, in this project: see #3622106. The section is left below as filed, for the record. Everything else in this issue — the switch to a Drupal CMS host, the job and stage renames, $DRUSH, the path-repository handling — is accurate and shipped.

drush site:install recipes/educare cannot complete on plain drupal/cms, with this error, at the time wrongly believed to be outside Educare:

Symfony\...\RuntimeException: You have requested a synthetic service ("kernel").
The DIC does not know how to construct this service. (ContainerBuilder.php:1104)

The chain: drupal_cms_helper 2.1.4 RecipeSubscriber::onApply() saves system.site during RecipeAppliedEvent, reaching Config::save(), then hasConfigSchema(), then TypedConfigManager::alterDefinitions(). That resolves every hook_config_schema_info_alter and so instantiates canvas/src/Hook/ComponentSourceHooks.php, which declares the config_schema_info_alter hook attribute and constructor-injects the kernel service by autowiring. During install the container is still a ContainerBuilder, where kernel is synthetic.

• Canvas 1.11.0. The autowire entered Canvas between 1.4.2 and 1.5.2.
• It reproduces with the stock drupal_cms_starter recipe and zero Educare code, and it also breaks the browser installer at 98%.
• Pinning Canvas back to 1.4.2 is not a workaround: Educare's own config then fails at ReferenceFieldTypePropExpression.php:210.

The consequence, as understood at the time: while that failure stood, this pipeline executed no functional tests at all and reported red. That held until the one-line recipe fix in #3622106 was found. The Varbase regression cover is given up deliberately, with the cost understood.

The install job is allow_failure: false on purpose. That is the opposite of what this issue proposed when it was filed, and the decision has been taken rather than left open: the job gates the whole suite, so allowing it to fail would produce a pipeline reporting green while running zero tests, which is worse than an honest red. No job in the file carries allow_failure: true, and nothing masks the install — the four || true in the file are all pre-existing lines carried over unchanged (corepack, an ImageMagick policy tweak, an optional antibot uninstall and a PDF report step); none is on the install or on anything that could hide its exit code.

What has been proven, and what has not

Executed and confirmed: the composer and drush mechanics were validated by running the job's exact lines through DDEV on a real drupal/cms build. The path repository with "options":{"symlink":false} mirrors rather than looping (Mirroring from educare-src), vendor/bin/drush runs, recipes/educare resolves, and drush site:install recipes/educare reaches the install and fails only on the documented synthetic-service error.

Unproven: everything after the install step — the cache round trip, npm install, playwright install chromium, the deterministic prep and sql:dump — is unreachable on a runner today and stays unverified. The job has never run end to end anywhere, and no pipeline has executed it to completion.

Remaining tasks

• ✅ File an issue
• ❌ Addition/Change/Update/Fix
• ❌ Testing to ensure no regression
• ❌ Run the pipeline for the first time on the remote runner and confirm it fails only on the documented upstream error
• ❌ Verify the steps after the install (cache, npm, Playwright, prep, sql:dump) once the install can succeed
• ❌ Restore script_failure to the install job's retry: once the install can succeed — it covers transient composer dist rate limits
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support
• ➖ User Guide Documentation support
• ➖ UX/UI designer responsibilities
• ➖ Accessibility and Readability
• ❌ Reviewed by a human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ❌ Review with the product owner
• ✅ Update Release Notes
• ✅ Release educare-1.0.2

User interface changes

• N/A

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• Switched functional testing to a Drupal CMS host only: the Varbase host build is removed, the test stage and jobs are renamed to functional, and the Drupal CMS install job now gates the suite. Until an upstream Canvas defect is fixed, the pipeline runs no functional tests and reports red.

AI-Generated: Yes