πŸ‡¦πŸ‡ΊAustralia @tobybellwood

Account created on 11 May 2017, over 7 years ago
  • Product Lead at amazee.ioΒ 
  • Director, Product Engineering - Lagoon at amazee.ioΒ  …
#

Merge Requests

Recent comments

πŸ‡¦πŸ‡ΊAustralia tobybellwood

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.

πŸ‡¦πŸ‡ΊAustralia 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.

πŸ‡¦πŸ‡ΊAustralia tobybellwood

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

πŸ‡¦πŸ‡ΊAustralia tobybellwood

Session Monitor for "Fractional vs. Full-Time Teams: Maximizing Efficiency and Expertise"

πŸ‡¦πŸ‡ΊAustralia tobybellwood

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.

πŸ‡¦πŸ‡ΊAustralia tobybellwood

I can confirm all is good in 11.0.x-dev - thanks for the swift fix team!

πŸ‡¦πŸ‡ΊAustralia tobybellwood

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!

πŸ‡¦πŸ‡ΊAustralia tobybellwood

closed in 3446110 with a more permissive requirement

πŸ‡¦πŸ‡ΊAustralia tobybellwood

I've just rerun in opensearch and can confirm that those fields are indeed missing from this branch, so will need readding in

πŸ‡¦πŸ‡ΊAustralia tobybellwood

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!

Production build 0.71.5 2024