Initial position:
Project Browser is not supported in production workloads on amazee.io or Lagoon
This is primarily because the filesystems are read-only, but there are other gotchas.
Nuanced position:
Project Browser (and by extension, Automatic Updates) can be enabled locally for Lagoon projects (but they probably shouldn't)
Note that these steps pertain to the default local environment install (https://github.com/pygmystack/pygmy). Success may vary on other local development tools (Lando, DDEV)
Steps:
1. Download the https://github.com/lagoon-examples/drupal-base project locally.
2. Bring the project up
docker compose up -d --build
3. Install Drupal and the modules (this is needed as the /app directory is mounted from the host)
docker compose exec cli bash -c "composer install"
4. Install a standard Drupal site via the UI at http://drupal-base.docker.amazee.io
5. Install and enable the project browser module
composer require 'drupal/project_browserβ
composer require 'drupal/automatic_updatesβ
drush en project_browser automatic_updates
6, Ensure that the "Allow Installing via the UI" box is ticked at http://drupal-base.docker.amazee.io/admin/config/development/project_bro...
7. In your browser visit the status report to see the errors http://drupal-base.docker.amazee.io/admin/reports/status
8. To address these errors:
Here are some of the errors we've encountered and their resolutions. Note that it might require a few reruns of the readiness checks to get it all to pass:
Composer was not found
Composer is by default only installed in the cli image, but for PB/AU to work, it needs to be in the php image too.
Add the following lines to the lagoon/php.Dockerfile
COPY --from=cli /usr/local/bin/composer /usr/local/bin/composer
RUN apk add --no-cache rsync
Then perform a docker compose build php && docker compose up -d
Any packages other than the implicitly allowed packages are not allowed to scaffold files.
amazee.io and Lagoon use a package to scaffold necessary files on composer install - and this is a known issue ( https://www.drupal.org/project/automatic_updates/issues/3350172 π Support any package to scaffold files Active )
docker compose exec cli bash -c "composer config extra.drupal-scaffold.allowed-packages --unset"
docker compose exec cli bash -c "composer config extra.drupal-scaffold.file-mapping --unset"
docker compose exec cli bash -c "composer update --no-install --lock"
Problems detected related to the Composer plugin cweagans/composer-patches.
This may be resolved in later versions of the Lagoon templates, but can be easily fixed.
docker compose exec cli bash -c "composer config extra.composer-exit-on-patch-failure true"
docker compose exec cli bash -c "composer update --no-install --lock"
9. Once all of the above have been resolved, any module can be installed with Project Browser, and updated with Automatic Updates. As the changes are reflected in the composer.json/lock, all updates can be pushed up with git. Note that unless config is exported, the modules may still need manually enabling.
10. To re-enable the amazeeio/drupal_integrations functionality, the missing blocks will need to be re-added to the extra.drupal-scaffold section in composer.json
Notes on this process
Because of the need to disable the amazeeio/drupal_integrations scaffold tooling, and the strong requirement for gitOps based workflows we don't currently recommend this path for users.
fubarhouse β credited tobybellwood β .
At amazee.io (and Lagoon-based hosting) our intention (currently*) is to run Drupal CMS projects in production that are almost identical in layout to ordinary Drupal Core projects - so any path to GitOps for our users would be to stand up our usual template - and export the db, config, files, and the composer files from the running site, probably via drush (which should work prod>local) - and this then should be enough to rebuild your running site locally (but there's a lot of R&D to do to see if this is indeed true, or whether there are other parts of the codebase that can be modified in Drupal CMS that we aren't across.
I wonder if there's also an option here to simply say, as a site owner "I know the scaffolding afforded by this plugin is safe, let's allow it to do what it does."
This would be ace - amazee.io & Lagoon hosters use https://github.com/amazeeio/drupal-integrations (or a variant) to lever in settings.php/Drush files.
Being able to document the plugin as "automatic updates safe" either upstream or in-project would make it easier. Until then, we run it once on composer install, and then `composer config extra.drupal-scaffold --unset` to stop it interfering with automatic updates.
The alternative would be a modification to composer-scaffold to disable it from autorunning selectively - meaning only `composer drupal:scaffold` will actually change the files on disk
dan2k3k4 β credited tobybellwood β .
Session Monitor for "Fractional vs. Full-Time Teams: Maximizing Efficiency and Expertise"
Registration from 13:00 to 15:00
I'll post an update on this next week - but there are several technical hurdles to overcome here:
* no writeable filesystem (container default)
* composer no available to the UI (runs in a CLI container currently)
* use of composer-scaffold in a default amazeeio/drupal-integrations install (workaround-able)
Any work we do to enable Project Browser/Automated updates (if we wanted to) would have to be on a specialised template.
I can confirm all is good in 11.0.x-dev - thanks for the swift fix team!
Thanks all for jumping in on this! Youβve obviously got it in hand, but Iβll also double double check when Iβm back at my desk.
Love your work!
tobybellwood β created an issue.
closed in 3446110 with a more permissive requirement
tobybellwood β created an issue.
froboy β credited tobybellwood β .
I've just rerun in opensearch and can confirm that those fields are indeed missing from this branch, so will need readding in
Thanks @guillaumeg - Iβll check the MR out once itβs up. IIRC there was something we needed to change for monolog 3, but canβt recall it!