gitlab-ci

REVIEWED 240531

The Drupal Association has introduced the use of gitlab-ci for running tests and other code analysis on Drupal modules. This blog post is an excellent guide for getting up and running with gitlab-ci. There is also some good documentation here. Here are the basic steps:

Setting it up

Navigate to your module’s source code page on drupalcode
click the plus icon, and select New file
enter .gitlab-ci.yml and watch an Apply a template dropdown appear
select template.gitlab-ci

That is enough to have gitlab running against the current Drupal version

Test against other versions

You can add a variables section to the file to broaden the versions tested against like so:

variables:
  # Broaden test coverage.
  OPT_IN_TEST_PREVIOUS_MAJOR: 1
  OPT_IN_TEST_MAX_PHP: 1
  OPT_IN_TEST_PREVIOUS_MINOR: 1
  OPT_IN_TEST_NEXT_MINOR: 1
  OPT_IN_TEST_NEXT_MAJOR: 1

As of this writing, this will cause the module to be tested against:

Drupal 10.2.x-dev with PHP 8.1 ← default run
Drupal 9.5.11 ← Previous major
Drupal 10.2.x-dev with PHP 8.3.4 ← max PHP
Drupal 10.1.8 ← Previous minor
Drupal 10.3.x-dev ← next minor
Drupal 11.x-dev ← next major

Resolve dependency issues

The next major release may fail if your module depends on another module that has not been marked compatible with the next major release. You can address this by adding a LENIENT_ALLOW_LIST configuration with the module or modules (comma separated) that should be allowed to install even if they aren’t marked compatible. If those dependencies require a patch you can provide a COMPOSER_PATCHES_FILE directive:

composer (next major):
  variables:
    LENIENT_ALLOW_LIST: dependency_1
    COMPOSER_PATCHES_FILE: .gitlab-ci/nextmajor_patches.json

Do some cleanup

After you have it set up and running, check the pipelines that have run, and clean up any issues found.

If cspell identifies spelling errors that should not be flagged (e.g. Kalamuna) you can add a file named .cspell-project-words.txt to your project root, with one word to be ignored by the spell checker per line.

Remove DrupalCI Schedules

The final step in removing the dependency on DrupalCI is to remove any automated tests runs scheduled.

Visit your module page and look at the releases on offer. Ensure that all of those branches have Gitlab CI enabled if needed.
Look for an Automated testing tab.
Click into that tab and under the DrupalCI (deprecated) section, click on “delete all DrupalCI testing schedules” and confirm on the next screen.
You should now see your module page with no Automated testing tab. Gitlab pipeline information can now be found on each release card.

Review History

Who	When	Status

Who	When	Status
Bob	20250531	Finished final draft