Composer
The composer
jobs are run automatically if a related job needs something from Composer. You cannot skip these jobs unless you skip PHPUnit and Nightwatch testing and also skip every validation/linting job that needs Composer.
Updating dependencies when testing against future releases
When testing against future versions of Drupal, the minimum stability value is automatically set to ‘dev’, regardless of the value set in composer.json
. Some dependencies may not be compatible with the target release, so they may need help to be enabled, using Lenient support and/or Composer patches.
Lenient support
The variable _LENIENT_ALLOW_LIST
can specify a comma-separated list of modules that Composer dependencies on the core version will be ignored for. This is achieved using the mglaman/composer-drupal-lenient Composer extension.
An example of this can be:
variables:
OPT_IN_TEST_NEXT_MINOR: '1'
OPT_IN_TEST_NEXT_MAJOR: '1'
OPT_IN_TEST_MAX_PHP: '1'
composer (next minor):
variables:
_LENIENT_ALLOW_LIST: token
composer (next major):
variables:
_LENIENT_ALLOW_LIST: entity_reference_revisions,inline_entity_form,paragraphs,token
In this example, the lenient plugin will NOT be used in the regular Composer task. But it will be used for the next minor and next major with different lists of projects that are allowed, even if those projects are not compatible with the new release.
Composer patches
Sometimes, you may need to install a patch for a dependent module to allow tests to pass.
To this, add a JSON file containing patches, and specify it in the _COMPOSER_PATCHES_FILE
variable. For example:
composer (next major):
variables:
_LENIENT_ALLOW_LIST: token
_COMPOSER_PATCHES_FILE: .gitlab-ci/nextmajor_patches.json
We recommend placing the patches within the .gitlab-ci
folder inside your module.
Additional information on the patch file can be found in the Composer Patches documentation.
Package versions
The templates will favor the drupal/core-recommended
package when installing Drupal, which does NOT include a composer.lock
file. This is expected and is the recommended usage for most cases.
If your module relies on specific versions of certain packages from core you need to update your module's composer.json
to declare this.
The composer
jobs in the templates set the expected Drupal core version, ignoring by default any possible core constraint set in the composer.json
file. If you want this constraint to be considered, you need to do the following:
composer:
variables:
IGNORE_PROJECT_DRUPAL_CORE_VERSION: 0
When to run yarn install
yarn install
is run inside the composer
job. If you want to change this so it does not, you just need to set _COMPOSER_YARN_INSTALL
to 0
and yarn install
will run when a job needs node_modules
binaries. One side effect of this is that node_modules
will not be part of the composer
artifacts.
If you have a custom job that requires node_modules
to be present and still want to use this feature, you can add this to the first line of the job's script
section: - !reference [ .get-node-modules ]
.
Request Entity Too Large
If you are getting this error in the composer
job, the generated artifact is too big in size to be saved.
The most common cases for this error are:
- Use of the development packages, as all git history is downloaded. The recommended fix is to use stable package versions.
- Assets downloaded are too big. Review the images, fonts, etc that you might be downloading to the project and adjust if possible. You can override the
.composer-base:artifacts:exclude
to exclude additional patterns. - The
node_modules
might be present in the artifacts, and it is too big. If that is the case, you can control the behavior via_COMPOSER_YARN_INSTALL
. Set it to0
to not runyarn install
on thecomposer
step, and the generated artifact size will be much smaller. It will be run in each of the subsequent jobs when required. The default is1
to runyarn install
only in thecomposer
job, and therefore thenode_modules
will be automatically kept and available for all subsequent jobs.