Disabling OPT_IN_TEST_CURRENT not working

The tests are running on Drupal 10.3.6, see https://git.drupalcode.org/project/gcds/-/jobs/3230835

If what you want is to run linting and tests under Drupal 10, I recommend the following:

composer:
  variables:
    DRUPAL_CORE: 10.3.6

And then removing the opt in to previous and the line to opt out of current. That will make current be D10, so linting and tests will be D10.

Yes, I found that solution. Still, I don't understand why OPT_IN_TEST_CURRENT doesn't work as documented.

The opt in variables are just for the tests jobs (phpunit and/or nightwatch).

The linting jobs are not influenced by the opt in test variables. Those are jobs for the “current” version, always. So the only way to change the version the run against is to alter what “current” is.

Maybe I’m just missing some details on what’s exactly the issue? What ran that shouldn’t under which condition?

It was failing at the Composer stage. I wanted to run only on Drupal 10 because a dependency does not have a Drupal 11 version. I fixed it with DRUPAL_CORE: 10.3.6. It needs to be documented better. I thought OPT_IN_TEST_CURRENT could be used to prevent all Drupal 11 testing.

Hi liam morland,
It's good that you have a solution to running the linting and coding standards jobs on D10 not D11. The variable descriptions in the link you gave necessarily have to be fairly brief, and I can see why it might have mislead you. The full documentation pages have much more detail. Here is the page explaining which jobs are run and when. We are reviewing all of these pages in 📌 Documentation pages Active so if there is something unclear or confusing or missing, please let us know.

Also I just wanted to check that you saw this blog post from August → where the switch-over process was explained. In particular, there are other ways that you can stay with D10 as "current", such as pinning your gitlab_templates version to 1.5.10 (the last version before the switch) until you are ready to use Drupal 11. In your .gitlab-ci.yml, in the include line at the top, change

    ref: $_GITLAB_TEMPLATES_REF

to
ref: '1.5.10'
then add

VARIABLES:
  _CURL_TEMPLATES_REF: '1.5.10'

As the "current" composer job is a dependency on other jobs ran in the pipeline, I'd say that this works as designed.
@jonathan1055 pointed out to some useful links, and specially 📌 Documentation pages Active where we are incrementally improving the documentation.

The pre-GitLab testing system was really easy to use. Just choose the version of Drupal, PHP, etc. and it worked. Once tests were working, they didn't change. I didn't have to read documentation or blog posts. I didn't have to reconfigure the tests following a new Drupal release. It was very friendly for maintainer.

In theory, the GitLab system allows me to write my own test config files. But I shouldn't have to learn all about writing test config just to get tests to run. The templates ought to easy to use and do the things that most people need done. That means having it run tests on the versions chosen by the maintainer and having those change only when the maintainer changes them.

The old system needed to be configured as well. It did not have an option for it to be "dynamic", so if you wanted to test newer versions you needed to go and configure them.

One of the goals of the new system was, from the beginning, for it to be dynamic "by default". Some maintainers like this new behaviour, some don't, and both options are fine. And you can choose which behaviour to follow, with a one-off configuration change.

When you first integrated GitLab CI, you copied the .gitlab-ci.yml file, and in the file it says:

It is also designed to keep up to date with Core Development automatically through the use of include files that can be centrally maintained.

It also says:

For information on alternative values for 'ref' see https://project.pages.drupalcode.org/gitlab_templates/info/templates-ver...

By leaving the default template unchanged, you are choosing a maintainer to keep the default behaviour. If you do not want versions to change (as this conversation clearly shows), you just need to change a couple of lines, and nothing will ever change anymore (until you decide to change it).

@jonathan1055's comment above shows you how, the documentation page shows you how, the blog post also shows you how, so it's really up to you whether you want to change it or not. You don't need to keep up with all the changes, blog posts, etc (because it is a one-off change, pinning the version), but I think it speaks well on the amount of work that we are doing, the options that we are offering and the availability of the information that maintainers have.

As the "current" composer job is a dependency on other jobs ran in the pipeline, I'd say that this works as designed.

I’ll note there is no reason that has to be the case for linting jobs, static analysis and tests(nightwatch/phpunit) yes they need a successful composer run, linting stages can be designed to operate standalone.

Agree that they could be standalone jobs (I think there was an issue for it), but for now they have that "shared" dependency.

It would be very helpful if the Templates behavior in contrib modules page included a table to help people select what template version to use, something like this:

Also, the .gitlab-ci.yml template includes the text "For information on alternative values for 'ref'". This isn't very helpful if you don't know what can be configured with ref. I suggest changing this text to something like "You can choose what version of Drupal core to test on by setting the value of 'ref' To learn about the options, see https://project.pages.drupalcode.org/gitlab_templates/info/templates-ver...".

I wouldn't put the table like that because it can be misleading, as 1.5.x-latest is not going to get any updates if bugs are found, but I agree on the overall feedback you just gave. I added it to https://www.drupal.org/project/gitlab_templates/issues/3473000#comment-1... 📌 Documentation pages Active so we can add some additional information and change the default template comments so they read better. Thanks.