ci: #3622102 Allow the Drupal CMS install job to fail while it is blocked upstream

Issue: #3622102 Allow the Drupal CMS install job to fail while it is blocked upstream

What this changes

allow_failure: true on 📦 (Drupal CMS) Install Educare site template, on the job and on its manual rule. It is the only job in the pipeline with allow_failure: true; the other seven remain false. One file, .gitlab-ci.yml, +18 / -11.

The header comment block is rewritten from "KNOWINGLY RED TODAY … Do not mask it" to "BLOCKED UPSTREAM … READ THIS BEFORE TRUSTING A GREEN PIPELINE", and the revert instruction is repeated on the job itself so it is visible from either place.

This reverses a decision made in #3622091 and merged in !61 (merged)

Stated openly rather than slipped in.

#3622091 / !61 (merged) made this job the gate for the suite and set it allow_failure: false deliberately, on the reasoning that a pipeline reporting green while running zero tests is worse than an honest red one. That reasoning was sound and is not being disowned here.

What changed is the evidence. That configuration has now run on a real drupal.org runner (pipeline 955303, job 12095450), and the result is a pipeline that is red on every branch and every merge request, permanently, for a defect this project does not own and cannot fix. A red signal that can never go green stops being a signal — it trains everyone to ignore the pipeline, including on the day a real Educare regression appears.

So this is a considered reversal, with the cost written into the file rather than hidden: the header block and the job comment both say what green now means and exactly what to restore.

Read this before trusting a green pipeline

While the upstream defect stands, a green pipeline here means "nothing broke in the jobs that ran". It does not mean "the tests passed".

The functional suite executes zero tests, because the site it needs is never built. A genuine Educare regression can hide behind green for as long as this lasts. That is the price of this change, and it is why the revert conditions are written into the file.

Revert conditions

Once the install job can succeed, restore both:

• allow_failure: false on the job and on its manual rule, and
• script_failure in the job's retry: (currently omitted so a guaranteed failure does not burn three full 2h builds per pipeline).

The cause is upstream, and it is not ours

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.

Reproduced four times independently:

1. A DDEV drupal/cms build.
2. The browser installer, dying at 98% — so it is not CLI-specific.
3. Stock drupal_cms_starter with zero Educare code — so it is not Educare-specific.
4. A clean drupal.org runner.

Pinning Canvas to 1.4.2 is not a workaround: Educare's config then fails at ReferenceFieldTypePropExpression.php:210.

This merge request proposes no change to Drupal CMS or to Canvas, and no patch. The job will go green on its own, with no edit to this file, once Canvas is fixed upstream.

What has and has not been verified

The allow_failure change itself has not been run at the time of writing. Nothing here should be read as the pipeline having been verified, and the functional suite does not pass — it does not execute.

The upstream failure it responds to has been observed on a real runner, in the four independent reproductions listed above.

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