Improve support of recipes
Is there an existing issue for this?
- [x] I have searched the existing issues
Is your feature request related to a problem?
Simple recipes without dependencies on other contrib dependencies just work with the current stack, however, recipes with dependencies on other recipes fail due to how the local development environment is set upped for them.
Describe your solution
The is already a 99% ready fix for this problem in the upstream Gitlab Templates repo, when the related fix is merged, we should identify the necessary changes here, if there will be any.
https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/408
Describe alternatives
No response
Additional context
No response
https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/408#note_604599
Now changes got merged and they found an interesting trick for resolving failing tests issues due to symlinks vs path resolving. We may try to do something similar in the phpunit custom command, that should be easy, however for those who prefers to use PHPstorm's Phpunit integration needs some other solution (maybe custom Phpunit bootstrap file that copies test files? I hoped I never need to maintain those again) or they have to get used to not relying on that for recipes.
https://git.drupalcode.org/project/gitlab_templates/-/commit/2104d0694f458b828eea17f19a61b01237ed036e
FTR external changes did not break our test suite :tada:
https://github.com/ddev/ddev-drupal-contrib/actions/runs/18923385758
WARNING: The list of project files and folders has been derived here, because the environment variable PROJECT_FILES is empty.
Array
(
[2] => .ddev
[3] => .editorconfig
[5] => .gitattributes
[6] => .gitlab-ci.yml
[7] => LICENSE.txt
[8] => README.md
[9] => composer.json
[10] => recipe.yml
[13] => tests
)
This may not be accurate and to avoid this warning, at the start of your customized composer script execute the following command:
export PROJECT_FILES=$(ls -A)
See change record https://www.drupal.org/node/3500320 for more details
************************************************************************************************************************
Creating symlinks in web/modules/custom/ai_recipe_llm_optimized_content/ pointing back to /var/www/html/ for the following files and folders:
.ddev
.editorconfig
.gitattributes
.gitlab-ci.yml
LICENSE.txt
README.md
composer.json
recipe.yml
tests
Restarted ai-recipe-llm-optimized-content
Creating symlinks in web/modules/custom/ai_recipe_llm_optimized_content/
hm, okay, what just happened? I thought we are getting the latest and greatest recipe support from "upstream"... but maybe some parts of the magic is in a place that were are not benefiting from. I need to re-read the MR diff.
so both the PROJECT_TYPE detection and the DRUPAL_PROJECT_FOLDER configuration based on the previous variable value and the custom handling of recipe tests are in includes/include.drupalci.main.yml, so we need to replicate these :sad-panda:
So far we have only supported contrib module development with this project - because module is the default PROJECT_TYPE. I have quickly confirmed that theory by creating a local dev env for Gin theme:
Creating symlinks in web/modules/custom/gin/ pointing back...
Update: there is only a documented manual workaround around approach for changing the symlink location: https://github.com/ddev/ddev-drupal-contrib?tab=readme-ov-file#changing-the-symlink-location
FYI the README briefly explains how to support a theme with this project https://github.com/ddev/ddev-drupal-contrib?tab=readme-ov-file#changing-the-symlink-location
Yep, just found it and updated the previous comment.
This is going to be more work than I expected but autodetection of project type would be a cool feature. What do you think?
Just to let you know that the message about PROJECT_FILES is not new in this latest release, its been there for a while.
Added in issue 3497525 https://www.drupal.org/project/gitlab_templates/issues/3497525 from 17th Jan.
I think its totally reasonable for themers and recipe authors to have to override things by hand. Thats my taste. I havent looked at this issue specifically - I'm just saying in general.