ci: #3622106 Correct the CI comments that still describe the install as blocked upstream

Issue: #3622106 drush site:install on a Drupal CMS host aborts with a synthetic service ("kernel") error

A second merge request on an already-resolved issue

This is a follow-up to !63 (merged), on the same issue, at the maintainer's request rather than as a new issue.

!63 (merged) fixed the install and is merged. It left behind documentation that describes the opposite situation: three comment blocks in .gitlab-ci.yml written while the failure was believed to be an unfixable upstream Canvas defect. Those comments are now wrong, and a wrong comment about a CI gate is the kind of thing that gets a future maintainer to mask the gate. This merge request corrects them.

What changes

One file, .gitlab-ci.yml, +21 / -33.

The only functional change is a single retry.when entry. Everything else in the diff is comment text. No job, stage, rule or script is changed; allow_failure: false is untouched everywhere; still 8 jobs.

1. Header block

Removed: "KNOWINGLY RED TODAY … it goes green on its own once Canvas is fixed upstream". Both halves are now false — the pipeline is green, and not because anything changed in Canvas.

Replaced with the rule that does still hold: every job is allow_failure: false, and the install gate must stay unmasked, because masking it skips the suite and the pipeline then reports green while running zero tests.

2. Job block

Removed: "this job is EXPECTED TO FAIL TODAY, and the cause is upstream, not in Educare".

Rewritten as history rather than deleted. It records what the failure looked like, that Canvas installs canvas_page_template_component lazily during RecipeAppliedEvent, that a mid-event module install rebuilds the container and leaves kernel synthetic, and that declaring the module in the recipe's install: list is the fix.

That is worth keeping: a future recipe change that reintroduces a mid-event module install will produce exactly this error, and the next person deserves the diagnosis rather than a fresh investigation. Credits #3622106 and Horizon Aid #3622092.

3. retry: comment, and the one functional change

The comment held script_failure back "while the upstream defect above stands … restore it once the install can actually succeed".

That condition is now met, so script_failure is restored to the install job's retry.when:

retry:
  max: 2
  when:
    - script_failure
    - runner_system_failure
    - stuck_or_timeout_failure

It covers transient github rate limits on composer dists, which is why it was there originally. It was removed only so a guaranteed failure would not burn three full 2h builds per pipeline.

Verification

No new verification of the install is claimed here. That was established by !63 (merged)'s pipeline 955403 — 23 of 23 jobs green, 233 scenarios and 1493 steps passed, with the install job green at allow_failure: false. This branch is that same code plus corrected comments, which is precisely why the comments are stale.

This branch's own pipeline is a sanity check, not new coverage. Note that with script_failure back in retry.when, a genuinely failing job will now retry up to 2 further times.

No patches. Nothing in Drupal CMS or Canvas is modified or proposed.

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