DRUPAL_CORE not taken into account

Thanks for reporting this. I'll investigate and get back.
It's great that some contrib pipelines are using 'main' ref, so we find these problems before rolling out to everyone using 'default' ref.

The failed composer job has a mismatch, it shows drupalConstraint = 10.3.x-dev
but that value should come directly from the env variable DRUPAL_CORE
https://git.drupalcode.org/project/sobki_profile_bootstrap/-/jobs/301706...

In this case, this module is setting a lot of the dependencies in the composer.json file, so this block https://git.drupalcode.org/project/gitlab_templates/-/blob/main/scripts/... might be conflicting with "require" vs "require-dev".

Note that this project is a profile, and that the templates are optimized for "modules", so this is a case that we are not covering by default.

The change was introduced in https://git.drupalcode.org/project/gitlab_templates/-/commit/761d8bc5251...

The fix might be (untested):

composer:
  variables:
    DRUPAL_CORE: 10.3.6
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 0

I think the depencies are fine, it is a problem with the scope of the variable. It is set globally in that project.
@grimreaper can you try remove the existing top-level definition of DRUPAL_CORE, then add it inside composer, via

composer:
  variables:
    DRUPAL_CORE: "10.3.6"

We need to document this better, and maybe improve the process too. But this should help get your pipeline working.

Oh! Good point, it could be that too!

I took the liberty of making that change on sobki_profile_bootstrap MR20 and it worked. We now get drupalConstraint = 10.3.6 in the composer job
https://git.drupalcode.org/issue/sobki_profile_bootstrap-3476709/-/jobs/...

Here's the full pipeline
https://git.drupalcode.org/issue/sobki_profile_bootstrap-3476709/-/pipel...

We can improve the variants/customizations doc page, and also make the deprecation message better. I'll open a MR here, as this may not be the last time someone has this problem.

Thanks so much for this @jonathan1055! Yeah, let's try to improve the documentation and provide examples of where/how to use DRUPAL_CORE.

An earlier test shows a deprecation job for 'composer next major' which is irrelevant, as _TARGET_CORE could only ever be used for 'current' and 'max php'
https://git.drupalcode.org/project/scheduler/-/pipelines/307178

I have improved this by checking the job name in the rules for the deprecation job, and the new pipeline only has two deprecation jobs, not three. In this pipeline I had a global _TARGET_CORE of 10.3.2 and another scoped for 'max php' set to 10.2.0. These different values are shown in the deprecation "use this instead" example. I added a temporary 'drush status' in the phpstan after_script to show that the value of _TARGET_CORE is still being honored:
https://git.drupalcode.org/project/scheduler/-/pipelines/307225

The message is better now, showing the actual job name and value for DRUPAL_CORE, and giving the proper way to use this within the scope of the appropriate composer job.

I have also documented how to override variables scoped within a particular variant.

Ready for review.

It looks good. I've asked a question on the MR. Setting to NW just based on that question for now.

Hi,

First, thanks a lot for the very quick reply!

Second, sorry I am staffed on another subject today, so I finally have some minutes to reply.

And thanks again to have tried and fixed the MR on my project!

I wonder if with the recent changes, as I have core version set in my composer.json, I still need to manually override the variable in .gitlab-ci.yml.

I will test quickly.

Your project is using the default gitlab_templates repo and ref

  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF

which means your "current" core version is Drupal 10, and specifically 10.3.x-dev so if this is what you want to test against, then you do not need to override the version.

This will all change on Monday, when we switch to Drupal 11 to be the "current" core version - see this blog post → and 📌 Update templates so 11.0 is the default/current branch RTBC for details (which you probably are already following anyway)

To answer your question on the MR, it is as I thought, the setting of DRUPAL_CORE that is done in the template variant jobs overrides the top-level value that a user might set, which is prefactly reasonable. So the user has override it within the scope of the variant job to have any effect.

In the folllowing test, I changed the top-level _TARGET_CORE: 10.3.2 to DRUPAL_CORE: 10.3.2 and only had _TARGET_CORE within the Max PHP job. The current composer core version does not get overridden and it uses CORE_STABLE as we see 11.0.5 in the log. So I think the documentation change needs to be like that.
https://git.drupalcode.org/project/scheduler/-/pipelines/308084

I have pushed a couple of minor changes. This is ready for review.

I've reviewed the code changes and the explanations as well as the new details in the documentation and it all makes sense to me.
Downstream pipelines: https://git.drupalcode.org/issue/gitlab_templates-3479986/-/pipelines/30...

RTBC.

Merged! Thanks for the improvements!

The latest version of my distro is built on Drupal 10.3.x. Recently it started testing against Drupal 11.x and failing. Adding the following to .gitlab-ci.yml fixed the issue for me:

composer:
  variables:
    DRUPAL_CORE: 10.3.6

Automatically closed - issue fixed for 2 weeks with no activity.