ci: #3622091 Add a Drupal CMS install job and switch functional testing to Drupal CMS only

Issue: #3622091 Add a Drupal CMS build-and-install job to the CI pipeline

What this changes

The scope grew past the issue title. This is no longer "add an optional smoke test" — it moves the whole functional pipeline onto Drupal CMS. One file, .gitlab-ci.yml, +110 / -58.

1. The Varbase host build is deleted. drupal/cms is now the only host project. VARBASE_PROJECT is gone, as are the two cache anchors that shared one key across two half-uses; they are replaced by a single .build_cache / .functional_cache pair on one key, educare-cms-build-v1-$CI_COMMIT_REF_SLUG, with the functional side policy: pull.
2. Renamed. Stage test becomes functional; job 🧪 varbase-e2e becomes 🧪 Functional, applied consistently across stages:, stage:, both needs:, dependencies: and the header block. VARBASE_E2E_REPORT_DISABLE and the @vardot/varbase-e2e package paths deliberately stay — that is the testing framework, not the host.
3. The install job now gates the entire suite. 🧪 Functional declares needs: ["📦 (Drupal CMS) Install Educare site template"].
4. New $DRUSH variable. drupal/cms sets bin-dir: vendor/bin, so drush is testsite/vendor/bin/drush. The functional job's DB restore, cache rebuild and runserver calls were all written as $SITE_DIR/bin/drush for the Varbase layout and would each have broken silently.
5. script_failure is deliberately left out of the install job's retry: while the install cannot pass — retrying a guaranteed failure would burn three full 2h builds per pipeline. The in-file comment says to restore it once the install can succeed. The 🧪 Functional job keeps script_failure.

The install job is allow_failure: false, on purpose

This reverses what an earlier revision of this merge request said, so it is worth being explicit.

The job fails today. It is still allow_failure: false, on the job and on its manual rule, because a pipeline that reported green while running zero tests would be worse than an honest red one. This is a deliberate choice, not an oversight.

The drush site:install command itself is not masked — no || true on it, and the real exit code is reported. (For accuracy: a few tolerant housekeeping steps elsewhere do carry || true — corepack enable, the ImageMagick WEBP policy edit, pm:uninstall antibot, and the PDF report step. None of them is the install.)

The consequence, accepted knowingly

Until the upstream Canvas defect is fixed, this pipeline executes no functional tests at all and reports red. The Varbase regression cover is being given up deliberately. That trade is the substance of this merge request and is the thing to review.

Why the install fails — upstream, not Educare

drupal_cms_helper RecipeSubscriber::onApply() calls Config::save(), which reaches TypedConfigManager::alterDefinitions(), which invokes Canvas ComponentSourceHooks. That class declares #[Hook('config_schema_info_alter')] and injects #[Autowire(service: 'kernel')] against a ContainerBuilder in which kernel is synthetic.

• Canvas 1.11.0; regression window 1.4.2 to 1.5.2.
• Reproduces on stock drupal_cms_starter with zero Educare code, and breaks the browser installer at 98%.
• It will go green with no edit to this job once Canvas is fixed.

This merge request proposes no change to Drupal CMS or to Canvas, and no patch.

What is proven, and what is not

Proven by execution. These exact lines were run through DDEV against a real drupal/cms build:

• composer config repositories.educare '{"type":"path",…,"options":{"symlink":false}}' --json followed by composer require drupal/educare:@dev --with-all-dependencies → Mirroring from educare-src, no symlink loop. (symlink:false is required; a symlinked path repo dies with "Too many levels of symbolic links".)
• vendor/bin/drush exists and runs; recipes/educare resolves.
• drush site:install recipes/educare … reaches the install and fails only on the documented upstream synthetic service ("kernel") error.

Not proven — stated plainly. Everything the job inherited from the deleted Varbase job sits after the install step, so on a runner today it will never be reached:

• the cache round-trip, npm install, playwright install chromium, the deterministic-prep steps, and the sql:dump artifact;
• whether the runner's cache restores testsite/ for the functional jobs under the new single key.

The job has never run end to end anywhere. Local gitlab-ci-local cannot close this gap: that machine cannot reach api.launchpad.net, which the shared host_php_setup before_script needs, so it stops before any of the job's own script runs. The remote pipeline will be its first real execution.

AI-Generated: Yes

Checkpoints

• Testing to ensure no regression
• Automated unit testing coverage
• Automated functional testing coverage
• Readability
• Accessibility
• Performance
• Security
• Developer Documentation
• User Guide Documentation
• Release notes snippet
• UX/UI designer responsibilities
• Reviewed by a human
• Code review by maintainers
• Full testing and approval
• Credit contributors
• Review with the product owner
• Release