Unable to run "composer (previous major)"; no image

Weird, it shouldn’t try the ubuntu image because of this line https://git.drupalcode.org/project/gitlab_templates/-/blob/main/includes...

Need to investigate why it does

I just tried on another project and it works as expected: https://git.drupalcode.org/project/keycdn/-/jobs/3278163

Are you overriding any variable from the gitlab UI?

I was setting _PHPUNIT_CONCURRENT: 0 in the UI to remove that as an issue, and make everything linear. But I've only done that since things started breaking. Not setting anything else other than what is in the file.

This is the file in use for main branch: https://git.drupalcode.org/project/genpass/-/blob/2.1.x/.gitlab-ci.yml?r...

Not sure if it's tangentially related, but I'm getting server 500 errors when simply accessing drupal core at admin/config/people/accounts without the contrib module even installed!. Locally, it works fine. I'm going nuts here. All of that worked a few days ago - it's in a release. 🐛 All phpunit testing failing Active is my testing of that issue.

Here's the 2.0.x branch failing to do previous major too:
https://git.drupalcode.org/project/genpass/-/pipelines/331567

Here the Site Verify module doing the same.
https://git.drupalcode.org/project/site_verify/-/jobs/3278516
It was working 4 days ago:
https://git.drupalcode.org/project/site_verify/-/pipelines/327677

Both of these use a .gitlab-ci.yml file I've written, so maybe I have some silly syntax error that just hasn't shown a fault until the last day?

Working (yours):

Running with gitlab-runner 17.5.2 (c6eae8d7)
  on gitlab-runner-6dd988d654-qvnk8 s8ex1X2yJ, system ID: r_EFUc8A4vR1Ul
Resolving secrets
Preparing the "kubernetes" executor
00:00
"CPURequest" overwritten with "2"
Using Kubernetes namespace: gitlab-runner
Using Kubernetes executor with image drupalci/php-8.1-apache:production ...

Failing (mine):

Running with gitlab-runner 17.5.2 (c6eae8d7)
  on gitlab-runner-6dd988d654-qvnk8 s8ex1X2yJ, system ID: r_EFUc8A4vR1Ul
Resolving secrets
Preparing the "kubernetes" executor
00:00
"CPURequest" overwritten with "2"
Using Kubernetes namespace: gitlab-runner
Using Kubernetes executor with image drupalci/php-8.1-ubuntu-apache:production ...

I didn't even know I could change that. And here's the normal composer (so Drupal 11.0.5 current), which fails at phpunit which I'm guessing is because it's running the wrong software. I can't even access vanilla Drupal core functionality:

Running with gitlab-runner 17.5.2 (c6eae8d7)
  on gitlab-runner-6dd988d654-qvnk8 s8ex1X2yJ, system ID: r_EFUc8A4vR1Ul
Resolving secrets
Preparing the "kubernetes" executor
00:00
"CPURequest" overwritten with "2"
Using Kubernetes namespace: gitlab-runner
Using Kubernetes executor with image drupalci/php-8.3-ubuntu-apache:production ...

You use php-8.1-apache:production, and I'm on php-8.3-ubuntu-apache. How did I do that? How can I fix it? afk 3 hours.

If you’re setting any variable via the UI (maybe scheduled pipelines) then you need to have a look to the _TARGET_PHP_IMAGE_VARIANT as the default value changed there.

The image and php version is set by the templates to the correct value. I’m still not sure why you’re getting this.

I’m afk now as well, I’ll put a snippet later so you can try a few things.

The tests failing might be a core issue 💬 Updating phpstan and twig via Composer generates a blank page when editing a node Active , most likely unrelated to the templates and it'll fix itself when they fix it in core.

The issue here is that the image is trying to get ubuntu-apache when we are forcing it in the templates to be apache.

I'll open an MR in your project to see if I can reproduce or if your issue is due to the variables set in the schedule.

I think the issue is on your end, I created an issue with the fix in 🐛 Test GitLab CI issue Active and the image loaded is correct.

I'd merge that and then see if the issue is resolved. Closing this one for now unless you reopen it.

The 💬 Updating phpstan and twig via Composer generates a blank page when editing a node Active issue is what was taking down a pile of my lives sites that I've also been pulling my hair out about, so turns out this is all interrelated. They're 10.3.6 sites, so it's extended further than dev!! Updated to twig 3.14.1 earlier today so just force backing that out to get things back up and running.

Looks like it was the indenting in the gitlab-ci file!! No idea what it just decided today to go bonkers. Probably an update of something that no longer accepts poorly indented yaml files. Didn't even know it was poorly indented as that came from the original gitlab_template file I grabbed that had the huge droplet at the bottom.

The main composer job is still going ubuntu! At least it's working. Here's the job you ran:
https://git.drupalcode.org/issue/genpass-3486092/-/jobs/3279675

Anyway, yes. Both my issues are fixed and all credit is to you, thank you.

Yeah, the main one is expected to run the ubuntu-apache variant, it's just the old ones (previous major) that should run the apache variant.

The reason for that is that the ubuntu- images ship with a newer sqlite version, and the change wasn't backported to old images, so this is what we have available: https://git.drupalcode.org/project/drupalci_environments/-/tree/dev/php?...

As you can see, only PHP 8.3 and 8.4 have the ubuntu variant, all previous PHP versions only have apache.

That core issue is spreading to many other places, I hope it's fixed soon.

Also, not sure why spacing worked before and not now, maybe an update upstream in GitLab itself. We updated the template a while back, removing the huge droplet and simplifying the code there, so maybe that was some of the things that were fixed.

I was curious about the indentation, because knowledge of this is important for when working on and maintaining Gitlab Templates. So I did a test, with indented variables
https://git.drupalcode.org/project/scheduler/-/merge_requests/201/diffs?...

and I'm pleased to say that the pipeline behaved exactly as before
https://git.drupalcode.org/project/scheduler/-/pipelines/332261

So I think the problems that caused this issue are not related to the indents. Which is good news for our understanding of how Gitlab pipelines are built.

I re-read your comments above, and see that you ran the pipeline from the UI. I have just tried this and sure enough it does fail for Previous Major, because it is trying to use image drupalci/php-8.1-ubuntu-apache:production
See https://git.drupalcode.org/project/scheduler/-/jobs/3285264

So I think we do have an issue for Gitlab Templates, when running from the UI. Therefore I have re-opened this, even though there are some unrelated problems above, as it does have good info in the comments. But if @fjgarlin would prefer a new issue we can do that.

Great test and find! Happy to continue here. My very first hint when the UI was mentioned was about the variables, but then working in the MR fixed things so I just thought it was that, because it was the only strange thing I could find.

The issue seems to be variables precedence https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence

Options are to create a new variable, like PHP_VERSION was created, and use that for the image generation. Then the original variable would only be used for “current”.

Another option, probably less desirable, can be to limit what gets run on manual runs, limiting to “current” only. I don’t think that this is even an option because we’ll lose functionality.

I was going to open this up again next week as I'm still having the issue - it does seem to be via the UI and also via MR. This issue has my workings on it 🐛 Test GitLab CI issue Active .

I pushed an override to the image to get this working for the 2.0.x branch. I tried just overriding for "composer (previous major)" but it would not accept it either, so everything now uses apache instead.

Strangely, 2.1.x branch works normal now, but 2.0.x does not. The 2.1.x was "fixed" by the indent, but it also does different core opt-ins. 2.0.x only tests phpunit on the previous major. 2.1.x does previous, current and next point phpunit.

Does DDev give me a local version of the gitlab runner setup?

Yes, I also think it is the variable precedence. I recall we discovered before that variables in the UI form override the variables in .gitlab-ci..yml, at all levels, so even if a job re-defines it's own value the form value will still be used. We could create a new variable, but also we could investigate whether moving it to the hidden-vars.yml would help?

I have not moved the variables (yet) to the hidden file, but just created internal variables $PHP_IMAGE_VARIANT and $PHP_IMAGE_TAG, which will never appear in the UI form, so can always be set correctly in the main.yml and main-d7.yml files. These can still be added manually in the UI if a user wants to force the values, but that would be the rarer case.

Pipeline from Scheduler MR all ran as expected. I add the values of the two new variables into the printout at the end of the log.
https://git.drupalcode.org/project/scheduler/-/pipelines/332884

Now we need to be able to test this change using a UI form. I'm not sure how to do that. Can we access the form on a MR branch?

Not directly for the MR, but you can go to the fork page, then go to Build > Pipelines > New pipeline and select the branch. I don't know if the effect will be the same as that of an MR, but it'll defo run the code of the fork.

The code looks exactly like what I had in mind.

I triggered a pipeline following the above (just from the fork page) and it seems to be showing up in the MR pipelines tab: https://git.drupalcode.org/project/scheduler/-/merge_requests/206/pipelines

Code wise, it looks really good.

For _TARGET_PHP_IMAGE_VARIANT and _TARGET_PHP_IMAGE_TAG, we should probably either change the description or just move the variables to the hidden file. Setting to "Needs work" based on that.

Tested in MR for Drupal 7 and all OK
https://git.drupalcode.org/project/scheduler/-/pipelines/332982

I'd prefer to move the variables to the hidden file, as we did with _TARGET_CORE and are intending to do with _TARGET_PHP, possibly in preparation for deprecating them (as we did with target_core). These variables which have to differ between variants I don't think belong in the UI form. Changing the values for these critical variables can be done easily in a project's .gitlab-ci.yml file, and that should be the preferred way. Or a user can manually add the variable to the form, but that's OK because they are taking responsibility for it. In the majority of cases the UI should be used for modifying the proper front-end options (skip, concurrent, opt_in, etc) which are proper global variables that do not need to change between variants (which is the origin of this issue/problem)

100% agree with all of it.

100% agree with all of it.

Thank you. I have move the three variables to the hidden file.

Good hint about using the fork repository -> pipelines -> new, then selecting the branch. Attached are screen shots of the form on the default 2.x branch and the MR fork, showing that the three variables are no longer in the form.

This is ready for review.

Code looks good to me. Tests from #17 and #21 confirm that the changes work. #23 shows the changes in the UI form.
Downstream pipelines: https://git.drupalcode.org/issue/gitlab_templates-3486021/-/pipelines/33...

RTBC (pending pipelines result).

Merged. Thanks!

BC break in pipelines that targeted PHP 8.1 which does not have an Ununtu image.
https://git.drupalcode.org/project/vault/-/jobs/3412515

Actually it is not this issue which caused your problem, it is an earlier one 🐛 SQLite version too low for Drupal 11 Active

Ah thanks! Didn’t follow the git blame far enough back (apparently I have the job on Monthly)

Yes that is a BC break for customized jobs which pin PHP at 8.1

There have been a couple of places recently (either issues or on Slack) where @fjgarlin has explained the design principles of Gitlab Templates, where things will be always moving forward to keep the majority of projects working with the latest core versions, etc, and that this may cause disruption for some custtomized tempates. We always have simple ways to solve the problem, and I think that we should document these on one the pages. Then it makes it easy for maintainers to find the support they need and see examples of the fixes. We can have a table of the version, date and explanation, much like change records.

I can work on that if it is approved as a plan.

I'd happily have "Change records" in issues when needed. We have the changelog, the documentation pages, and the deprecation jobs, but sometimes we can't foresee or cover all situations, so yeah, a change record that explains the change and what needs to be done would be good.

Maybe we can make the first "Change record" be the image change that caused some BC issues.

Created ✨ Release ubuntu images for PHP 8.1 and 8.2 Active

Shall I still create a change record for 🐛 SQLite version too low for Drupal 11 Active given the new issue you created? If that may take some time to get done we can have the change record anyway.

Yeah, it won't hurt to have it. If the other issue is fixed, we would still want people to review their integrations (if they look at the change records).

(at the risk of continuing/bringing us further off topic from the original issue that i incorrectly posted on to begin with)

the design principles of Gitlab Templates, where things will be always moving forward to keep the majority of projects working with the latest core versions,

Moving forward is fine, I have absolutely no issue with that.

Quoting myself from 🐛 SQLite version too low for Drupal 11 Active

Reminder that the rule for BC was basically if a maintainer needed to make changes to their .gitlab-ci.yml in response to a change in gitlab_templates it needed to be a major branch release.

(this is a slight oversimplification as there were a few breaks and changes that were speced in like $_CORE_STABLE will always be the current highest stable release)

It costs absolutely nothing more to "git tag 2.0.0" vs "git tag 1.99.99"
The vast majority of projects will/are using $_GITLAB_TEMPLATES_REF and have agreed to follow breaking changes across gitlab_template major branches. They will follow and have no reason to object as they agreed to breaking changes. Even a number of my projects are still using $_GITLAB_TEMPLATES_REF as I haven't taken the time to go in and change it to 1.x-latest. Eventually the repo will move to 2.x and that that will break something and I'll blame myself for that if I have not gone in and locked my versions. I just have not prioritized it as @fjgarlin has made it abundantly clear gitlab_template refuses to consider a 2.x branch anytime in the near future allowing me to de-prioritize the concern under the expectation gitlab_templates will not break my existing deployments,(and will do their best to foresee and avoid those breaks) or if it does gitlab_templates will roll out a fix that allows me to avoid touching my own .gitlab-ci.yml. Those maintainers who have chosen 1.x-latest may find that something new doesn't work, such as a new core major, and they have to change to 2.x-latest at that point, it was however a was a part of the agreement the maintainer makes when locking to a specific release series.

✨ Release ubuntu images for PHP 8.1 and 8.2 Active is a reasonable fix, it meets the condition of undoing the break. The key point i am trying to make is uphold the promise that was made when a versioning policy was created, these were known issues that should have prevented 🐛 SQLite version too low for Drupal 11 Active from being merged until the non-breaking aspects were implemented.

Change records are great for 'when I'm ready to move forward with a new major' and I mean none of this to say that shouldn't be done, just that they are not the solution to the root issue we have been hitting more frequently of ignoring the wider impact of changes.

I agree with pretty much everything you say (including my push for not considering 2.x).

Our goal for now is to really try to keep things consistent and BC compatible, we are trying to factor that in pretty much all issues. However we cannot foresee some things, or we just fail to see it, and we are reacting to them in those occasions.

I'm trying to avoid the 2.0.0 tags (and therefore be ok with non-BC changes) because I still think that we can accommodate most of the needs, and we have designed workarounds for deprecations, as a results of pushing ourselves to not break existing pipelines.

2.0.0 will inevitably come at some point, but I think the longer we can keep things compatible the better as we are still getting projects onboarded onto GitLab CI. Maybe my perception of the 2.x series is just too "ideal" in the sense that I'd like to refactor and optimise a few too many things, and that's why I'm hesitant about it, but yeah, if we consider 2.x as "this new change is not BC, but we aren't really changing anything else", maybe it's not that much of a leap. But we still want to keep things as stable and compatible as possible as we have nearly 3k integrations already.

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