The functional suite cannot log in because the Drupal CMS installer ignores --account-name, and rename the two pipeline jobs

Problem/Motivation

Since #3622094 the pipeline builds one host (Drupal CMS) and the functional suite runs against it. On the first full run the install job passed, but 9 of the 18 functional buckets failed: 09-editorial-a, 09-editorial-b, 09-editorial-c, 10-01-canvas-pages-listed, 10-02-canvas-home-about, 10-03-canvas-countries-programs, 10-04-canvas-resources-events, 10-05-canvas-impact-donate and 12-search. The 9 that passed are the ones that never log in.

Every failure is the same step, with the same cause:

Given I am a logged in user with the "webmaster" user   PASS
Then I should see "Log out"                              FAIL
  locator.waitFor: Timeout 5000ms exceeded.
  waiting for locator('body').filter({ hasText: 'Log out' }) to be visible

The account does not exist. The Drupal CMS installer's "Create your account" step has no username field - its only inputs are account[mail], account[pass] and date_default_timezone (verified in a real browser). So drush site:install drupal_cms_installer --account-name=webmaster silently ignores the username, and user 1 is always admin.

Confirmed on two freshly built sites on plain Drupal CMS: after both drush site:install recipes/horizonaid and a full browser install, User::load(1)->getAccountName() returns admin. The suite's cucumber.js defines its users as webmaster / dD.123123ddd, so no scenario needing an authenticated user can pass.

This did not surface before because the removed varbase_project lane installed with drush site:install recipes/horizonaid on a Varbase host, where --account-name IS honoured.

Separately, two job names should be shortened: Install Horizon Aid site template (Drupal CMS) to Drupal CMS - Horizon Aid, and Functional testing to Functional.

Steps to reproduce

1. Build a plain Drupal CMS host and require the recipe:
   

   composer create-project drupal/cms
   composer config minimum-stability dev
   composer require drupal/horizonaid:1.0.x-dev

2. Install it:
   

   drush site:install drupal_cms_installer installer_site_template_form.add_ons=horizonaid --account-name=webmaster --account-pass=dD.123123ddd -y

3. Read back the account name:
   

   drush ev 'print \Drupal\user\Entity\User::load(1)->getAccountName();'

   Expected: webmaster. Actual: admin.

4. Run any functional bucket that logs in - every scenario fails on Then I should see "Log out".

Environment: Drupal core 11.4.6, plain drupal/cms, drupal/canvas 1.11.0, PHP 8.4, DDEV, MariaDB, no patches of any kind.

Proposed resolution

1. In the install job, after the site is installed, rename user 1 to $DRUPAL_ADMIN_USERNAME and set its password explicitly, with a comment explaining that the installer's account step has no username field.
2. Rename the two jobs to Drupal CMS - Horizon Aid and Functional.

Verified locally: on a freshly built Drupal CMS site with Horizon Aid installed, renaming user 1 to webmaster and setting the password makes the login work - driven in a real browser, the login lands on /admin/dashboard and "Log out" is present, which is exactly the step that was failing. The rewritten pipeline is accepted by the GitLab CI lint API (valid: true).

Note for the queue - a separate, more serious defect found while verifying this, which this issue does NOT fix

Installing Horizon Aid through the browser installer (clicking through Drupal CMS's own installer and picking the Horizon Aid template) breaks part-way. The progress bar stops around "Completed 41 of 123", the installer still redirects to /admin/dashboard/welcome, and the result is a site-wide HTTP 500 on every route, including the front page and /user/login. Only 77 of 245 modules end up installed; vartheme_bs5_horizonaid and redirect are among the missing, while redirect.settings, views.view.redirect, views.view.redirect_404 and language.content_settings.redirect.redirect were still imported, so the first fatal is PluginNotFoundException: The "redirect" entity type does not exist. The drush-driven paths (drush site:install recipes/horizonaid and drush site:install drupal_cms_installer installer_site_template_form.add_ons=horizonaid) both complete cleanly on the same codebase, so this is specific to the browser installer. This looks like the same defect already reported as #3620718 - please check and either fold this evidence in there or open a dedicated issue.

Remaining tasks

• ✅ File an issue
• ❌ Addition/Change/Update/Fix
• ❌ Testing to ensure no regression
• ➖ 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

User interface changes

• N/A

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• N/A

AI policy disclosure

AI-Generated: Yes

Assisted by Claude Code / Claude Opus 5, per the Policy on the use of AI when contributing to Drupal. The findings above were verified locally by human-run installs, a real browser login and the GitLab CI lint API.