Open loopy3025 opened 1 month ago
I am wondering if this is an intentional aspect of drupal-recommended-settings and I should just let it happen.
I have noticed, when ssh into these sites, that some seem to have changed the permissions to -r--r--r--. On the site I am currently working on, the settings.php file has not been included in the deployment artefact at all. This is most perplexing.
I've gone and added settings.php to the gitignore then added git add -f docroot/sites/default/settings.php
to the build artefact step in pipelines. I am 99% sure the file is being added during composer install
. The file is still not in the build artefact. I am really not sure what's going on here.
Pipelines is definitely adding the file to the commit. It just isn't making it to the build artefact itslef somehow.
As it turns out, the missing settings file is an issue with Acquia's ODE environments.
However, I still think it's weird that the settings.php file gets chmod to 777 during composer install.
We have decided to add the docroot/sites/default/settings.php
to our gitignore file and just let drupal-recommended-settings do whatever it wants there. The file does get committed to the build artefact without the need to add -f
to the git add
command.
Describe the bug On
composer install
, drupal-recommended-settings runs/home/ide/project/vendor/bin/drush drs:init:settings
. When it does this, permissions on settings.php change from 644 to 755.To Reproduce
Expected behavior Permissions on settings.php should be 644 on a drupal website.
Environment Happening both locally and during pipelines ci, so ci fails on a check dirty.
Additional context I have tried adding the file to file-mapping in composer, but that also doesn't work. The chmod still happens.
Although I really don't want to do this anyways because it wouldn't capture future patches to settings.php.
For now I will add a hook that re-chmods the file but this is weird.