Is CORE_SECURITY_PREVIOUS_MINOR the right version for "previous minor"

Slack thread with some comments that made me create this issue: https://drupal.slack.com/archives/C03L6441E1W/p1721851858152709

Possible workarounds for the above situation:

variables:
  CORE_SECURITY_PREVIOUS_MINOR: 10.2.7

or

composer (previous minor):
  variables:
    DRUPAL_CORE: 10.2.7

Though this will not make sense anymore if a new 10.2.X release is a security one.

Another slack thread: https://drupal.slack.com/archives/C1BMUQ9U6/p1752176458373939

TLDR; this one says that for the hook classes that were added to 11.1, the hook order classes didn't make it into the latest security release. that leads to a problem if you need to use them.

I really think that it's more confusing to have the security version rather than the latest stable previous minor.

I added the new variable, made the needed checks.

First test with wrong value (so the script detects it): https://git.drupalcode.org/project/gitlab_templates/-/jobs/5854307
Second test with the correct value: https://git.drupalcode.org/project/gitlab_templates/-/jobs/5854320

I am keeping all the logic for the other variable as we do it for a few other values, even if they are not used within the templates.

This is ready for review.

Looks good, left a couple of suggestions in the MR.

Do we need to consider BC here? If a custom template has set the old variable CORE_SECURITY_PREVIOUS_MINOR to something, expecting that to be used in 'prevoius minor'. Not sure how we do that, as the old variable still has a value within this new set-up. So we can't check for whether it has a value. There is a way to reference variables from other sections, so could we give a warning if CORE_SECURITY_PREVIOUS_MINOR has a value other than the value defined in hidden-variables.yml ?

Thanks for the suggestions, I've applied those.

I don't really think we need to do anything about BC in this case. We are changing the behaviour very slightly, for something that probably makes even more sense, and we are documenting it. One could even argue that using that value was a bug. It's similar to what we did here: 📌 Use stable core versions Active .

We can post a message in #slack or even create a change record, tho I don't think that the latter is needed.

Yes, that's OK with no BC. You are right that there isn't really any case to solve. No CR but a simple message in slack would be good. Also I have changed the issue title to be specific, and we can make sure the commit message and changelog are very clear (those are more important as they persist, whereas a message in Slack may only be seen by a few)

I have added the (unrelated) missing word to .gitignore as per the discussion on #3532272-13: ESLint needs to ignore /vendor folder →

I have also swapped round the display order of CORE_PREVIOUS_MINOR and CORE_SECURITY_PREVIOUS_MINOR so that the sequence is sort of getting older as the list goes down. Easier to understand 11.1.8 then 11.1.5 then 10.5.1. New output is

Current values of the variables             Variant where this is used
- CORE_STABLE:                  11.2.2      Current and max PHP
- CORE_SECURITY:                11.1.5      <unused>
- CORE_SUPPORTED:               11.2.x-dev  <unused>
- CORE_PREVIOUS_MINOR:          11.1.8      Previous Minor
- CORE_SECURITY_PREVIOUS_MINOR: 11.1.5      <unused>
- CORE_PREVIOUS_STABLE:         10.5.1      Previous Major
- CORE_MINOR:                   11.x-dev    <unused>
- CORE_NEXT_MINOR:              11.x-dev    Next Minor
- CORE_MAJOR_DEVELOPMENT:       <empty>     Next Major
- CORE_LEG_STABLE:              7.103       Drupal 7 tests

The Check Code job failed with

$ # Bash standards. # collapsed multi-line command
/scripts-186820-5876141/step_script: line 235: shellcheck: command not found

After the install command apt-get update && apt-get install -y shellcheck we do see 404 Not Found [IP: 151.101.22.132 80]

The code changes you did look good. RTBC on that part.

As for the "shellcheck" issue. There were some updates in the runners last week, which I think should not affect this. Maybe the image we use was updated in "drupalci_environments", I'm not sure.

I saw this here: https://support.atlassian.com/bitbucket-cloud/kb/error-404-failed-to-fet...

I changed the image from 8.1 to 8.3 and that seems to work well. So RTBC.

Merged. Thanks!

Thanks for changing the image, nice that shellcheck is OK again.

For BC there is just one project using CORE_SECURITY_PREVIOUS_MINOR and this is because they have copied the entire includes/include.drupalci.main.yml file from Gitlab Templates to be their own .gitlab-ci.yml. That feels like the maintainer of rift_cq → has mis-understood the way that the template works.

Thanks for opening the issue. I was going to suggest that (opening the issue in the project). It might have been a conscious decision, but if it isn't, we can help them keep the simple version.

I did something similar on August 24th via slack with the "pdf_api" maintainer (https://git.drupalcode.org/project/pdf_api/-/commit/e2afe127128845cd4453...).

Maybe we need to make something more obvious in https://project.pages.drupalcode.org/gitlab_templates/info/setup/ .
For example, in https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → we have:

Note: You do NOT need to copy in any of the other 'include' files, GitLab will reference those directly from the template.

Thanks for that. I've added the text to both of the paragraphs in the documentation MR328

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