Moving installation from /var/www/html to /opt/drupal/web caused breakage.
Closed this issue · 5 comments
On August 6, our test script in AWS CodeBuild broke. Apparently Drupal installation isn't being installed in /var/www/html within the container anymore.
Now we keep getting this error:
OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "exec: \"./run-updates.sh\": stat ./run-updates.sh: no such file or directory": unknown
--
Is there a good reason why this was changed?
Were you using drupal:latest in your test script? Because that changed from pointing to drupal:8 to drupal:9. If that's true, and without knowing your use-case, I would guess that explicitly referencing drupal:8 (instead of drupal:latest) would solve it for you. Then you can take the time to understand the changes in the Drupal 9 image, which is built via Composer and Drupal's new Recommended Project template: https://www.drupal.org/docs/develop/using-composer/starting-a-site-using-drupal-composer-project-templates
Here is the PR that made the change for D9: #176
And the original issue: #169
Hope that helps!
The 8 images were also changed in #176 to use Drupal's recommend layout. We tried to keep everything backwards compatible so that mounts to /var/www/html/modules (and others as documented on the Docker Hub page) would still work.
It seems that you are dropping a file into /var/www/html explicitly and then relying on the WORKDIR to run it? Unfortunately the WORKDIR was changed to accommodate child images to easily install extra composer packages ( like RUN composer require 'drupal/paragraphs:^1.12'). I would suggest to either COPY the file into ./ or be explicit about both where you put it and where you run it from.
@yosifkit Yes, that's exactly what we have in our setup. We assume that the workdir will be the same. Now that it's different, everything is broken.
Are we going to have to reorganize our entire directory structure to support Drupal 9? Because that wasn't described at DrupalCon.
You can see a diff over in #176 (comment). Which boils down to compose.json, .lock, and vendor/ have moved, but are still in the direct WORKDIR and everything else is in ./web/ (but still accessible as /var/www/html).
We would like to understand how users expect to be able to customize the drupal image for their deployments. Would it be possible to share your Dockerfile and build context along with a docker run or docker-compose.yml file?
Closing old issue.